From suenaga at oss.nttdata.com Wed Apr 1 01:02:42 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 1 Apr 2020 10:02:42 +0900 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: <8ced0d82-4125-7179-bac2-c8ce54807274@oracle.com> References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <8ced0d82-4125-7179-bac2-c8ce54807274@oracle.com> Message-ID: Thanks Dan and Serguei! I added a comment for this to JDK-8201641. David, can you share Bug ID for thread-to-thread handshake? I want to record it to JDK-8201641 as a blocker. Yasumasa On 2020/04/01 1:59, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > Yes, this works needs to be done. > I'll take look at you webrev. > > Thanks, > Serguei > > On 3/31/20 07:41, Daniel D. Daugherty wrote: >> Add Robbin to this thread... >> >> >> This reminded of the following RFE that Robbin filed: >> >> ??? JDK-8201641 JVMTI: GetThreadListStackTraces should use Thread-Local Handshakes >> ??? https://bugs.openjdk.java.net/browse/JDK-8201641 >> >> We could update 8201641 to include everything that Yasumasa-san is requesting. >> Would be a good place to track it... >> >> Dan >> >> >> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> On 2020/03/31 19:16, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Many JVMTI functions uses VM Operation to get information. However some of them need to stop only one thread - they don't need to stop all threads. >>>>> So I think we can use Thread Local Handshake as this webrev. It is example for GetOneCurrentContendedMonitor(). >>>> >>>> True, but at the moment handshakes involve the VMThread. There is work being done to support direct thread-to-thread handshakes and once that is done this kind of conversion should be more easily done. It might be worth waiting for that. >>> >>> Thanks, I will be back to this topic when thread-to-thread handshake is done. >>> I wondered at first why VMThread involves handshake. Its improvement is welcome for me ;) >>> >>> >>> Cheers, >>> >>> Yasumasa >>> >>> >>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>> >>>> An observation, it seems to me that calling_thread is not used when this is not a VMOperation. >>>> >>>> Cheers, >>>> David >>>> >>>>> Also I think we can replace following VM Operations to Thread Local Handshake: >>>>> >>>>> class VM_GetCurrentLocation >>>>> class VM_EnterInterpOnlyMode >>>>> class VM_UpdateForPopTopFrame >>>>> class VM_SetFramePop >>>>> class VM_GetOwnedMonitorInfo >>>>> class VM_GetCurrentContendedMonitor >>>>> class VM_GetFrameCount >>>>> class VM_GetFrameLocation >>>>> >>>>> What do you think? >>>>> It it is acceptable, I will file it to JBS and send review request. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >> > From mandy.chung at oracle.com Wed Apr 1 03:01:10 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Mar 2020 20:01:10 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> Thanks to the review feedbacks. Updated webrev: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ Delta between webrev.03 and webrev.04: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ Summary of changes is: 1. Update javac to retain the previous behavior when compiling to target release <= 14 where lambda proxy class is not a nestmate 2. Rename Class::isHiddenClass to Class::isHidden 3. Address Joe's feedback on the CSR to document the behavior of the relevant methods in java.lang.Class for hidden classes 4. Add test case for unloadable class with nest host error 5. Add test cases for hidden classes with different kinds of class or interface 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class" 7. Small changes in response to Remi, Coleen, Paul's review comments 8. Fix copyright headers 9. Fix @modules in tests Most of the changes above have also been reviewed as separate patches. Thanks Mandy On 3/26/20 4:57 PM, Mandy Chung wrote: > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area.? Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.reingruber at sap.com Wed Apr 1 06:15:12 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 1 Apr 2020 06:15:12 +0000 Subject: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: <1f8a3c7a-fa0f-b5b2-4a8a-7d3d8dbbe1b5@oracle.com> <4b56a45c-a14c-6f74-2bfd-25deaabe8201@oracle.com> <5271429a-481d-ddb9-99dc-b3f6670fcc0b@oracle.com> Message-ID: Hi Martin, > thanks for addressing all my points. I've looked over webrev.5 and I'm satisfied with your changes. Thanks! > I had also promised to review the tests. Thanks++ I appreciate it very much, the tests are many lines of code. > test/jdk/com/sun/jdi/EATests.java > This is a substantial amount of tests which is appropriate for a such a large change. Skipping some subtests with UseJVMCICompiler makes sense because it doesn't provide the necessary JVMTI functionality, yet. > Nice work! > I also like that you test with and without BiasedLocking. Your tests will still be fine after BiasedLocking deprecation. Hope so :) > Very minor nits: > - 2 typos in comment above EARelockingNestedInflatedTarget: "lockes are ommitted" (sounds funny) > - You sometimes write "graal" and sometimes "Graal". I guess the capital G is better. (Also in EATestsJVMCI.java.) > test/jdk/com/sun/jdi/EATestsJVMCI.java > EATests with Graal enabled. Nice that you support Graal to some extent. Maybe Graal folks want to enhance them in the future. I think this is a good starting point. Will change this in the next webrev. > Conclusion: Looks good and not trivial :-) > Now, you have one full review. I'd be ok with covering 2nd review by partial reviews. > Compiler and JVMTI parts are not too complicated IMHO. > Runtime part should get at least one additional careful review. Thanks a lot, Richard. -----Original Message----- From: Doerr, Martin Sent: Dienstag, 31. M?rz 2020 16:01 To: Reingruber, Richard ; 'Robbin Ehn' ; Lindenmaier, Goetz ; David Holmes ; Vladimir Kozlov (vladimir.kozlov at oracle.com) ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, thanks for addressing all my points. I've looked over webrev.5 and I'm satisfied with your changes. I had also promised to review the tests. test/hotspot/jtreg/serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java Thanks for updating the @summary comment. Looks good in webrev.5. test/hotspot/jtreg/serviceability/jvmti/Heap/libIterateHeapWithEscapeAnalysisEnabled.c JVMTI agent for object tagging and heap iteration. Good. test/jdk/com/sun/jdi/EATests.java This is a substantial amount of tests which is appropriate for a such a large change. Skipping some subtests with UseJVMCICompiler makes sense because it doesn't provide the necessary JVMTI functionality, yet. Nice work! I also like that you test with and without BiasedLocking. Your tests will still be fine after BiasedLocking deprecation. Very minor nits: - 2 typos in comment above EARelockingNestedInflatedTarget: "lockes are ommitted" (sounds funny) - You sometimes write "graal" and sometimes "Graal". I guess the capital G is better. (Also in EATestsJVMCI.java.) test/jdk/com/sun/jdi/EATestsJVMCI.java EATests with Graal enabled. Nice that you support Graal to some extent. Maybe Graal folks want to enhance them in the future. I think this is a good starting point. Conclusion: Looks good and not trivial :-) Now, you have one full review. I'd be ok with covering 2nd review by partial reviews. Compiler and JVMTI parts are not too complicated IMHO. Runtime part should get at least one additional careful review. Best regards, Martin > -----Original Message----- > From: Reingruber, Richard > Sent: Montag, 30. M?rz 2020 10:32 > To: Doerr, Martin ; 'Robbin Ehn' > ; Lindenmaier, Goetz > ; David Holmes ; > Vladimir Kozlov (vladimir.kozlov at oracle.com) > ; serviceability-dev at openjdk.java.net; > hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance > in the Presence of JVMTI Agents > > Hi, > > this is webrev.5 based on Robbin's feedback and Martin's review - thanks! :) > > The change affects jvmti, hotspot and c2. Partial reviews are very welcome > too. > > Full: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.5/ > Delta: > http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.5.inc/ > > Robbin, Martin, please let me know, if anything shouldn't be quite as you > wanted it. Also find my > comments on your feedback below. > > Robbin, can I count you as Reviewer for the runtime part? > > Thanks, Richard. > > -- > > > DeoptimizeObjectsALotThread is only used in compileBroker.cpp. > > You can move both declaration and definition to that file, no need to > clobber > > thread.[c|h]pp. (and the static function deopt_objs_alot_thread_entry) > > Done. > > > Does JvmtiDeferredUpdates really need to be in thread.hpp, can't be in it's > own > > hpp file? It doesn't seem right to add JVM TI classes into thread.hpp. > > I moved JvmtiDeferredUpdates to vframe_hp.hpp where preexisting > jvmtiDeferredLocalVariableSet is > declared. > > > src/hotspot/share/code/compiledMethod.cpp > > Nice cleanup! > > Thanks :) > > > src/hotspot/share/code/debugInfoRec.cpp > > src/hotspot/share/code/debugInfoRec.hpp > > Additional parmeters. (Remark: I think "non_global_escape_in_scope" > would read better than "not_global_escape_in_scope", but your version is > consistent with existing code, so no change request from my side.) Ok. > > I've been thinking about this too and finally stayed with > not_global_escape_in_scope. It's supposed > to mean an object whose escape state is not GlobalEscape is in scope. > > > src/hotspot/share/compiler/compileBroker.cpp > > src/hotspot/share/compiler/compileBroker.hpp > > Extra thread for DeoptimizeObjectsALot. (Remark: I would have put it into > a follow up change together with the test in order to make this webrev > smaller, but since it is included, I'm reviewing everything at once. Not a big > deal.) Ok. > > Yes the change would be a little smaller. And if it helps I'll split it off. In > general I prefer > patches that bring along a suitable amount of tests. > > > src/hotspot/share/opto/c2compiler.cpp > > Make do_escape_analysis independent of JVMCI capabilities. Nice! > > It is the main goal of the enhancement. It is done for C2, but could be done > for JVMCI compilers > with just a small effort as well. > > > src/hotspot/share/opto/escape.cpp > > Annotation for MachSafePointNodes. Your added functionality looks > correct. > > But I'd prefer to move the bulky code out of the large function. > > I suggest to factor out something like has_not_global_escape and > has_arg_escape. So the code could look like this: > > SafePointNode* sfn = sfn_worklist.at(next); > > sfn->set_not_global_escape_in_scope(has_not_global_escape(sfn)); > > if (sfn->is_CallJava()) { > > CallJavaNode* call = sfn->as_CallJava(); > > call->set_arg_escape(has_arg_escape(call)); > > } > > This would also allow us to get rid of the found_..._escape_in_args > variables making the loops better readable. > > Done. > > > It's kind of ugly to use strcmp to recognize uncommon trap, but that seems > to be the way to do it (there are more such places). So it's ok. > > Yeah. I copied the snippet. > > > src/hotspot/share/prims/jvmtiImpl.cpp > > src/hotspot/share/prims/jvmtiImpl.hpp > > The sequence is pretty complex: > > VM_GetOrSetLocal element initialization executes EscapeBarrier code > which suspends the target thread (extra VM Operation). > > Note that the target threads have to be suspended already for > VM_GetOrSetLocal*. So it's mainly the > synchronization effect of EscapeBarrier::sync_and_suspend_one() that is > required here. Also no extra > _handshake_ is executed, since sync_and_suspend_one() will find the > target threads already > suspended. > > > VM_GetOrSetLocal::doit_prologue performs object deoptimization (by VM > Thread to prepare VM Operation with frame deoptimization). > > VM_GetOrSetLocal destructor implicitly calls EscapeBarrier destructor > which resumes the target thread. > > But I don't have any improvement proposal. Performance is probably not a > concern, here. So it's ok. > > > VM_GetOrSetLocal::deoptimize_objects deoptimizes the top frame if it > has non-globally escaping objects and other frames if they have arg escaping > ones. Good. > > It's not specifically the top frame, but the frame that is accessed. > > > src/hotspot/share/runtime/deoptimization.cpp > > Object deoptimization. I have more comments and proposals, here. > > First of all, handling recursive and waiting locks in relock_objects is tricky, > but looks correct. > > Comments are sufficient to understand why things are done as they are > implemented. > > > BiasedLocking related parts are complex, but we may get rid of them in the > future (with BiasedLocking removal). > > Anyway, looks correct, too. > > > Typo in comment: "regularily" => "regularly" > > > Deoptimization::fetch_unroll_info_helper is the only place where > _jvmti_deferred_updates get deallocated (except JavaThread destructor). > But I think we always go through it, so I can't see a memory leak or such kind > of issues. > > That's correct. The compiled frame for which deferred updates are allocated > is always deoptimized > before (see EscapeBarrier::deoptimize_objects()). This is also asserted in > compiledVFrame::update_deferred_value(). I've added the same assertion > to > Deoptimization::relock_objects(). So we can be sure that > _jvmti_deferred_updates are deallocated > again in fetch_unroll_info_helper(). > > > EscapeBarrier::deoptimize_objects: ResourceMark should use > calling_thread(). > > Sure, well spotted! > > > You can use MutexLocker and MonitorLocker with Thread* to save the > Thread::current() call. > > Right, good hint. This was recently introduced with 8235678. I even had to > resolve conflicts. Should > have done this then. > > > I'd make set_objs_are_deoptimized static and remove it from the > EscapeBarrier interface because I think it shouldn't be used outside of > EscapeBarrier::deoptimize_objects. > > Done. > > > Typo in comment: "we must only deoptimize" => "we only have to > deoptimize" > > Replaced with "[...] we deoptimize iff local objects are passed as args" > > > "bool EscapeBarrier::deoptimize_objects(intptr_t* fr_id)" is trivial and > barrier_active() is redundant. Implementation can get moved to hpp file. > > Ok. Done. > > > I'll get back to suspend flags, later. > > > There are weird cases regarding _self_deoptimization_in_progress. > > Assume we have 3 threads A, B and C. A deopts C, B deopts C, C deopts C. > C can set _self_deoptimization_in_progress while A performs the handshake > for suspending C. I think this doesn't lead to errors, but it's probably not > desired. > > I think it would be better to use only one "wait" call in > sync_and_suspend_one and sync_and_suspend_all. > > You're right. We've discussed that face-to-face, but couldn't find a real issue. > But now, thinking again, a reckon I found one: > > 2808 // Sync with other threads that might be doing deoptimizations > 2809 { > 2810 // Need to switch to _thread_blocked for the wait() call > 2811 ThreadBlockInVM tbivm(_calling_thread); > 2812 MonitorLocker ml(EscapeBarrier_lock, > Mutex::_no_safepoint_check_flag); > 2813 while (_self_deoptimization_in_progress) { > 2814 ml.wait(); > 2815 } > 2816 > 2817 if (self_deopt()) { > 2818 _self_deoptimization_in_progress = true; > 2819 } > 2820 > 2821 while (_deoptee_thread->is_ea_obj_deopt_suspend()) { > 2822 ml.wait(); > 2823 } > 2824 > 2825 if (self_deopt()) { > 2826 return; > 2827 } > 2828 > 2829 // set suspend flag for target thread > 2830 _deoptee_thread->set_ea_obj_deopt_flag(); > 2831 } > > - A waits in 2822 > - C is suspended > - B notifies all in resume_one() > - A and C wake up > - C wins over A and sets _self_deoptimization_in_progress = true in 2818 > - C does the self deoptimization > - A executes 2830 _deoptee_thread->set_ea_obj_deopt_flag() > > C will self suspend at some undefined point. The resulting state is illegal. > > > I first thought it'd be better to move ThreadBlockInVM before wait() to > reduce thread state transitions, but that seems to be problematic because > ThreadBlockInVM destructor contains a safepoint check which we shouldn't > do while holding EscapeBarrier_lock. So no change request. > > Yes, would be nice to have the state change only if needed, but for the > reason you mentioned it is > not quite as easy as it seems to be. I experimented as well with a second > lock, but did not succeed. > > > Change in thred_added: > > I think the sequence would be more comprehensive if we waited for > deopt_all_threads in Thread::start and all other places where a new thread > can run into Java code (e.g. JVMTI attach). > > Your version makes new threads come up with suspend flag set. That looks > correct, too. Advantage is that you only have to change one place > (thread_added). It'll be interesting to see how it will look like when we use > async handshakes instead of suspend flags. > > For now, I'm ok with your version. > > I had a version that did what you are suggesting. The current version also has > the advantage, that > there are fewer places where a thread has to wait for ongoing object > deoptimization. This means > viewer places where you have to worry about correct thread state > transitions, possible deadlocks, > and if all oops are properly Handle'ed. > > > I'd only move MutexLocker ml(EscapeBarrier_lock...) after if (!jt- > >is_hidden_from_external_view()). > > Done. > > > Having 4 different deoptimize_objects functions makes it a little hard to > keep an overview of which one is used for what. > > Maybe adding suffixes would help a little bit, but I can also live with what > you have. > > Implementation looks correct to me. > > 2 are internal. I added the suffix _internal to them. This leaves 2 to choose > from. > > > src/hotspot/share/runtime/deoptimization.hpp > > Escape barriers and object deoptimization functions. > > Typo in comment: "helt" => "held" > > Done in place already. > > > src/hotspot/share/runtime/interfaceSupport.cpp > > InterfaceSupport::deoptimizeAllObjects() is only used for > DeoptimizeObjectsALot = 1. > > I think DeoptimizeObjectsALot = 2 is more important, but I think it's not bad > to have DeoptimizeObjectsALot = 1 in addition. Ok. > > I never used DeoptimizeObjectsALot = 1 that much. It could be more > deterministic in single threaded > scenarios. I wouldn't object to get rid of it though. > > > src/hotspot/share/runtime/stackValue.hpp > > Better reinitilization in StackValue. Good. > > StackValue::obj_is_scalar_replaced() should not return true after calling > set_obj(). > > > src/hotspot/share/runtime/thread.cpp > > src/hotspot/share/runtime/thread.hpp > > src/hotspot/share/runtime/thread.inline.hpp > > wait_for_object_deoptimization, suspend flag, deferred updates and test > feature to deoptimize objects. > > > In the long term, we want to get rid of suspend flags, so it's not so nice to > introduce a new one. But I agree with G?tz that it should be acceptable as > temporary solution until async handshakes are available (which takes more > time). So I'm ok with your change. > > I'm keen to build the feature on async handshakes when the arive. > > > You can use MutexLocker with Thread*. > > Done. > > > JVMTIDeferredUpdates: I agree with Robin. It'd be nice to move the class > out of thread.hpp. > > Done. > > > src/hotspot/share/runtime/vframe.cpp > > Added support for entry frame to new_vframe. Ok. > > > > src/hotspot/share/runtime/vframe_hp.cpp > > src/hotspot/share/runtime/vframe_hp.hpp > > > I think code()->as_nmethod() in not_global_escape_in_scope() and > arg_escape() should better be under #ifdef ASSERT or inside the assert > statement (no need for code cache walking in product build). > > Done. > > > jvmtiDeferredLocalVariableSet::update_monitors: > > Please add a comment explaining that owner referenced by original info > may be scalar replaced, but it is deoptimized in the vframe. > > Done. > > -----Original Message----- > From: Doerr, Martin > Sent: Donnerstag, 12. M?rz 2020 17:28 > To: Reingruber, Richard ; 'Robbin Ehn' > ; Lindenmaier, Goetz > ; David Holmes ; > Vladimir Kozlov (vladimir.kozlov at oracle.com) > ; serviceability-dev at openjdk.java.net; > hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance > in the Presence of JVMTI Agents > > Hi Richard, > > > I managed to find time for a (almost) complete review of webrev.4. (I'll > review the tests separately.) > > First of all, the change seems to be in pretty good quality for its significant > complexity. I couldn't find any real bugs. But I'd like to propose minor > improvements. > I'm convinced that it's mature because we did substantial testing. > > I like the new functionality for object deoptimization. It can possibly be > reused for future escape analysis based optimizations. So I appreciate having > it available in the code base. > In addition to that, your change makes the JVMTI implementation better > integrated into the VM. > > > Now to the details: > > > src/hotspot/share/c1/c1_IR.hpp > describe_scope parameters. Ok. > > > src/hotspot/share/ci/ciEnv.cpp > src/hotspot/share/ci/ciEnv.hpp > Fix for JvmtiExport::can_walk_any_space() capability. Ok. > > > src/hotspot/share/code/compiledMethod.cpp > Nice cleanup! > > > src/hotspot/share/code/debugInfoRec.cpp > src/hotspot/share/code/debugInfoRec.hpp > Additional parmeters. (Remark: I think "non_global_escape_in_scope" > would read better than "not_global_escape_in_scope", but your version is > consistent with existing code, so no change request from my side.) Ok. > > > src/hotspot/share/code/nmethod.cpp > Nice cleanup! > > > src/hotspot/share/code/pcDesc.hpp > Additional parameters. Ok. > > > src/hotspot/share/code/scopeDesc.cpp > src/hotspot/share/code/scopeDesc.hpp > Improved implementation + additional parameters. Ok. > > > src/hotspot/share/compiler/compileBroker.cpp > src/hotspot/share/compiler/compileBroker.hpp > Extra thread for DeoptimizeObjectsALot. (Remark: I would have put it into a > follow up change together with the test in order to make this webrev > smaller, but since it is included, I'm reviewing everything at once. Not a big > deal.) Ok. > > > src/hotspot/share/jvmci/jvmciCodeInstaller.cpp > Additional parameters. Ok. > > > src/hotspot/share/opto/c2compiler.cpp > Make do_escape_analysis independent of JVMCI capabilities. Nice! > > > src/hotspot/share/opto/callnode.hpp > Additional fields for MachSafePointNodes. Ok. > > > src/hotspot/share/opto/escape.cpp > Annotation for MachSafePointNodes. Your added functionality looks correct. > But I'd prefer to move the bulky code out of the large function. > I suggest to factor out something like has_not_global_escape and > has_arg_escape. So the code could look like this: > SafePointNode* sfn = sfn_worklist.at(next); > sfn->set_not_global_escape_in_scope(has_not_global_escape(sfn)); > if (sfn->is_CallJava()) { > CallJavaNode* call = sfn->as_CallJava(); > call->set_arg_escape(has_arg_escape(call)); > } > This would also allow us to get rid of the found_..._escape_in_args variables > making the loops better readable. > > It's kind of ugly to use strcmp to recognize uncommon trap, but that seems > to be the way to do it (there are more such places). So it's ok. > > > src/hotspot/share/opto/machnode.hpp > Additional fields for MachSafePointNodes. Ok. > > > src/hotspot/share/opto/macro.cpp > Allow elimination of non-escaping allocations. Ok. > > > src/hotspot/share/opto/matcher.cpp > src/hotspot/share/opto/output.cpp > Copy attribute / pass parameters. Ok. > > > src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp > Nice cleanup! > > > src/hotspot/share/prims/jvmtiEnv.cpp > src/hotspot/share/prims/jvmtiEnvBase.cpp > Escape barriers + deoptimize objects for target thread. Good. > > > src/hotspot/share/prims/jvmtiImpl.cpp > src/hotspot/share/prims/jvmtiImpl.hpp > The sequence is pretty complex: > VM_GetOrSetLocal element initialization executes EscapeBarrier code which > suspends the target thread (extra VM Operation). > VM_GetOrSetLocal::doit_prologue performs object deoptimization (by VM > Thread to prepare VM Operation with frame deoptimization). > VM_GetOrSetLocal destructor implicitly calls EscapeBarrier destructor which > resumes the target thread. > But I don't have any improvement proposal. Performance is probably not a > concern, here. So it's ok. > > VM_GetOrSetLocal::deoptimize_objects deoptimizes the top frame if it has > non-globally escaping objects and other frames if they have arg escaping > ones. Good. > > > src/hotspot/share/prims/jvmtiTagMap.cpp > Escape barriers + deoptimize objects for all threads. Ok. > > > src/hotspot/share/prims/whitebox.cpp > Added WB_IsFrameDeoptimized to API. Ok. > > > src/hotspot/share/runtime/deoptimization.cpp > Object deoptimization. I have more comments and proposals, here. > First of all, handling recursive and waiting locks in relock_objects is tricky, but > looks correct. > Comments are sufficient to understand why things are done as they are > implemented. > > BiasedLocking related parts are complex, but we may get rid of them in the > future (with BiasedLocking removal). > Anyway, looks correct, too. > > Typo in comment: "regularily" => "regularly" > > Deoptimization::fetch_unroll_info_helper is the only place where > _jvmti_deferred_updates get deallocated (except JavaThread destructor). > But I think we always go through it, so I can't see a memory leak or such kind > of issues. > > EscapeBarrier::deoptimize_objects: ResourceMark should use > calling_thread(). > > You can use MutexLocker and MonitorLocker with Thread* to save the > Thread::current() call. > > I'd make set_objs_are_deoptimized static and remove it from the > EscapeBarrier interface because I think it shouldn't be used outside of > EscapeBarrier::deoptimize_objects. > > Typo in comment: "we must only deoptimize" => "we only have to > deoptimize" > > "bool EscapeBarrier::deoptimize_objects(intptr_t* fr_id)" is trivial and > barrier_active() is redundant. Implementation can get moved to hpp file. > > I'll get back to suspend flags, later. > > There are weird cases regarding _self_deoptimization_in_progress. > Assume we have 3 threads A, B and C. A deopts C, B deopts C, C deopts C. C > can set _self_deoptimization_in_progress while A performs the handshake > for suspending C. I think this doesn't lead to errors, but it's probably not > desired. > I think it would be better to use only one "wait" call in > sync_and_suspend_one and sync_and_suspend_all. > > I first thought it'd be better to move ThreadBlockInVM before wait() to > reduce thread state transitions, but that seems to be problematic because > ThreadBlockInVM destructor contains a safepoint check which we shouldn't > do while holding EscapeBarrier_lock. So no change request. > > Change in thred_added: > I think the sequence would be more comprehensive if we waited for > deopt_all_threads in Thread::start and all other places where a new thread > can run into Java code (e.g. JVMTI attach). > Your version makes new threads come up with suspend flag set. That looks > correct, too. Advantage is that you only have to change one place > (thread_added). It'll be interesting to see how it will look like when we use > async handshakes instead of suspend flags. > For now, I'm ok with your version. > > I'd only move MutexLocker ml(EscapeBarrier_lock...) after if (!jt- > >is_hidden_from_external_view()). > > Having 4 different deoptimize_objects functions makes it a little hard to keep > an overview of which one is used for what. > Maybe adding suffixes would help a little bit, but I can also live with what you > have. > Implementation looks correct to me. > > > src/hotspot/share/runtime/deoptimization.hpp > Escape barriers and object deoptimization functions. > Typo in comment: "helt" => "held" > > > src/hotspot/share/runtime/globals.hpp > Addition of develop flag DeoptimizeObjectsALotInterval. Ok. > > > src/hotspot/share/runtime/interfaceSupport.cpp > InterfaceSupport::deoptimizeAllObjects() is only used for > DeoptimizeObjectsALot = 1. > I think DeoptimizeObjectsALot = 2 is more important, but I think it's not bad > to have DeoptimizeObjectsALot = 1 in addition. Ok. > > > src/hotspot/share/runtime/interfaceSupport.inline.hpp > Addition of deoptimizeAllObjects. Ok. > > > src/hotspot/share/runtime/mutexLocker.cpp > src/hotspot/share/runtime/mutexLocker.hpp > Addition of EscapeBarrier_lock. Ok. > > > src/hotspot/share/runtime/objectMonitor.cpp > Make recursion count relock aware. Ok. > > > src/hotspot/share/runtime/stackValue.hpp > Better reinitilization in StackValue. Good. > > > src/hotspot/share/runtime/thread.cpp > src/hotspot/share/runtime/thread.hpp > src/hotspot/share/runtime/thread.inline.hpp > wait_for_object_deoptimization, suspend flag, deferred updates and test > feature to deoptimize objects. > > In the long term, we want to get rid of suspend flags, so it's not so nice to > introduce a new one. But I agree with G?tz that it should be acceptable as > temporary solution until async handshakes are available (which takes more > time). So I'm ok with your change. > > You can use MutexLocker with Thread*. > > JVMTIDeferredUpdates: I agree with Robin. It'd be nice to move the class out > of thread.hpp. > > > src/hotspot/share/runtime/vframe.cpp > Added support for entry frame to new_vframe. Ok. > > > src/hotspot/share/runtime/vframe_hp.cpp > src/hotspot/share/runtime/vframe_hp.hpp > > I think code()->as_nmethod() in not_global_escape_in_scope() and > arg_escape() should better be under #ifdef ASSERT or inside the assert > statement (no need for code cache walking in product build). > > jvmtiDeferredLocalVariableSet::update_monitors: > Please add a comment explaining that owner referenced by original info may > be scalar replaced, but it is deoptimized in the vframe. > > > src/hotspot/share/utilities/macros.hpp > Addition of NOT_COMPILER2_OR_JVMCI_RETURN macros. Ok. > > > test/hotspot/jtreg/serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysi > sEnabled.java > test/hotspot/jtreg/serviceability/jvmti/Heap/libIterateHeapWithEscapeAnal > ysisEnabled.c > New test. Will review separately. > > > test/jdk/TEST.ROOT > Addition of vm.jvmci as required property. Ok. > > > test/jdk/com/sun/jdi/EATests.java > test/jdk/com/sun/jdi/EATestsJVMCI.java > New test. Will review separately. > > > test/lib/sun/hotspot/WhiteBox.java > Added isFrameDeoptimized to API. Ok. > > > That was it. Best regards, > Martin > > > > -----Original Message----- > > From: hotspot-compiler-dev > bounces at openjdk.java.net> On Behalf Of Reingruber, Richard > > Sent: Dienstag, 3. M?rz 2020 21:23 > > To: 'Robbin Ehn' ; Lindenmaier, Goetz > > ; David Holmes > ; > > Vladimir Kozlov (vladimir.kozlov at oracle.com) > > ; serviceability-dev at openjdk.java.net; > > hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > > dev at openjdk.java.net > > Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better > > Performance in the Presence of JVMTI Agents > > > > Hi Robbin, > > > > > > I understand that Robbin proposed to replace the usage of > > > > _suspend_flag with handshakes. Apparently, async handshakes > > > > are needed to do so. We have been waiting a while for removal > > > > of the _suspend_flag / introduction of async handshakes [2]. > > > > What is the status here? > > > > > I have an old prototype which I would like to continue to work on. > > > So do not assume asynch handshakes will make 15. > > > Even if it would, I think there are a lot more investigate work to remove > > > _suspend_flag. > > > > Let us know, if we can be of any help to you and be it only testing. > > > > > >> Full: > > http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4/ > > > > > DeoptimizeObjectsALotThread is only used in compileBroker.cpp. > > > You can move both declaration and definition to that file, no need to > > clobber > > > thread.[c|h]pp. (and the static function deopt_objs_alot_thread_entry) > > > > Will do. > > > > > Does JvmtiDeferredUpdates really need to be in thread.hpp, can't be in > it's > > own > > > hpp file? It doesn't seem right to add JVM TI classes into thread.hpp. > > > > You are right. It shouldn't be declared in thread.hpp. I will look into that. > > > > > Note that we also think we may have a bug in deopt: > > > https://bugs.openjdk.java.net/browse/JDK-8238237 > > > > > I think it would be best, if possible, to push after that is resolved. > > > > Sure. > > > > > Not even nearly a full review :) > > > > I know :) > > > > Anyways, thanks a lot, > > Richard. > > > > > > -----Original Message----- > > From: Robbin Ehn > > Sent: Monday, March 2, 2020 11:17 AM > > To: Lindenmaier, Goetz ; Reingruber, > Richard > > ; David Holmes > ; > > Vladimir Kozlov (vladimir.kozlov at oracle.com) > > ; serviceability-dev at openjdk.java.net; > > hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- > > dev at openjdk.java.net > > Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance > > in the Presence of JVMTI Agents > > > > Hi, > > > > On 2/24/20 5:39 PM, Lindenmaier, Goetz wrote: > > > Hi, > > > > > > I had a look at the progress of this change. Nothing > > > happened since Richard posted his update using more > > > handshakes [1]. > > > But we (SAP) would appreciate a lot if this change could > > > be successfully reviewed and pushed. > > > > > > I think there is basic understanding that this > > > change is helpful. It fixes a number of issues with JVMTI, > > > and will deliver the same performance benefits as EA > > > does in current production mode for debugging scenarios. > > > > > > This is important for us as we run our VMs prepared > > > for debugging in production mode. > > > > > > I understand that Robbin proposed to replace the usage of > > > _suspend_flag with handshakes. Apparently, async handshakes > > > are needed to do so. We have been waiting a while for removal > > > of the _suspend_flag / introduction of async handshakes [2]. > > > What is the status here? > > > > I have an old prototype which I would like to continue to work on. > > So do not assume asynch handshakes will make 15. > > Even if it would, I think there are a lot more investigate work to remove > > _suspend_flag. > > > > > > > > I think we should no longer wait, but proceed with > > > this change. We will look into removing the usage of > > > suspend_flag introduced here once it is possible to implement > > > it with handshakes. > > > > Yes, sure. > > > > >> Full: > http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4/ > > > > DeoptimizeObjectsALotThread is only used in compileBroker.cpp. > > You can move both declaration and definition to that file, no need to > clobber > > thread.[c|h]pp. (and the static function deopt_objs_alot_thread_entry) > > > > Does JvmtiDeferredUpdates really need to be in thread.hpp, can't be in it's > > own > > hpp file? It doesn't seem right to add JVM TI classes into thread.hpp. > > > > Note that we also think we may have a bug in deopt: > > https://bugs.openjdk.java.net/browse/JDK-8238237 > > > > I think it would be best, if possible, to push after that is resolved. > > > > Not even nearly a full review :) > > > > Thanks, Robbin > > > > > > >> Incremental: > > >> > http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4.inc/ > > >> > > >> I was not able to eliminate the additional suspend flag now. I'll take care > > of this > > >> as soon as the > > >> existing suspend-resume-mechanism is reworked. > > >> > > >> Testing: > > >> > > >> Nightly tests @SAP: > > >> > > >> JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, > > Renaissance > > >> Suite, SAP specific tests > > >> with fastdebug and release builds on all platforms > > >> > > >> Stress testing with DeoptimizeObjectsALot running SPECjvm2008 40x > > parallel > > >> for 24h > > >> > > >> Thanks, Richard. > > >> > > >> > > >> More details on the changes: > > >> > > >> * Hide DeoptimizeObjectsALotThread from external view. > > >> > > >> * Changed EscapeBarrier_lock to be a _safepoint_check_never lock. > > >> It used to be _safepoint_check_sometimes, which will be eliminated > > sooner or > > >> later. > > >> I added explicit thread state changes with ThreadBlockInVM to code > > paths > > >> where we can wait() > > >> on EscapeBarrier_lock to become safepoint safe. > > >> > > >> * Use handshake EscapeBarrierSuspendHandshake to suspend target > > threads > > >> instead of vm operation > > >> VM_ThreadSuspendAllForObjDeopt. > > >> > > >> * Removed uses of Threads_lock. When adding a new thread we > suspend > > it iff > > >> EA optimizations are > > >> being reverted. In the previous version we were waiting on > > Threads_lock > > >> while EA optimizations > > >> were reverted. See EscapeBarrier::thread_added(). > > >> > > >> * Made tests require Xmixed compilation mode. > > >> > > >> * Made tests agnostic regarding tiered compilation. > > >> I.e. tc isn't disabled anymore, and the tests can be run with tc enabled > or > > >> disabled. > > >> > > >> * Exercising EATests.java as well with stress test options > > >> DeoptimizeObjectsALot* > > >> Due to the non-deterministic deoptimizations some tests need to be > > skipped. > > >> We do this to prevent bit-rot of the stress test code. > > >> > > >> * Executing EATests.java as well with graal if available. Driver for this is > > >> EATestsJVMCI.java. Graal cannot pass all tests, because it does not > > provide all > > >> the new debug info > > >> (namely not_global_escape_in_scope and arg_escape in > > scopeDesc.hpp). > > >> And graal does not yet support the JVMTI operations force early > return > > and > > >> pop frame. > > >> > > >> * Removed tracing from new jdi tests in EATests.java. Too much trace > > output > > >> before the debugging > > >> connection is established can cause deadlock because output buffers > fill > > up. > > >> (See https://bugs.openjdk.java.net/browse/JDK-8173304) > > >> > > >> * Many copyright year changes and smaller clean-up changes of testing > > code > > >> (trailing white-space and > > >> the like). > > >> > > >> > > >> -----Original Message----- > > >> From: David Holmes > > >> Sent: Donnerstag, 19. Dezember 2019 03:12 > > >> To: Reingruber, Richard ; serviceability- > > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > > hotspot- > > >> runtime-dev at openjdk.java.net; Vladimir Kozlov > > (vladimir.kozlov at oracle.com) > > >> > > >> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better > > Performance in > > >> the Presence of JVMTI Agents > > >> > > >> Hi Richard, > > >> > > >> I think my issue is with the way EliminateNestedLocks works so I'm going > > >> to look into that more deeply. > > >> > > >> Thanks for the explanations. > > >> > > >> David > > >> > > >> On 18/12/2019 12:47 am, Reingruber, Richard wrote: > > >>> Hi David, > > >>> > > >>> > > > Some further queries/concerns: > > >>> > > > > > >>> > > > src/hotspot/share/runtime/objectMonitor.cpp > > >>> > > > > > >>> > > > Can you please explain the changes to ObjectMonitor::wait: > > >>> > > > > > >>> > > > ! _recursions = save // restore the old recursion count > > >>> > > > ! + jt->get_and_reset_relock_count_after_wait(); // > > >>> > > > increased by the deferred relock count > > >>> > > > > > >>> > > > what is the "deferred relock count"? I gather it relates to > > >>> > > > > > >>> > > > "The code was extended to be able to deoptimize objects of a > > >>> > > frame that > > >>> > > > is not the top frame and to let another thread than the > owning > > >>> > > thread do > > >>> > > > it." > > >>> > > > > >>> > > Yes, these relate. Currently EA based optimizations are reverted, > > when a > > >> compiled frame is > > >>> > > replaced with corresponding interpreter frames. Part of this is > > relocking > > >> objects with eliminated > > >>> > > locking. New with the enhancement is that we do this also just > > before > > >> object references are > > >>> > > acquired through JVMTI. In this case we deoptimize also the > > owning > > >> compiled frame C and we > > >>> > > register deoptimized objects as deferred updates. When control > > returns > > >> to C it gets deoptimized, > > >>> > > we notice that objects are already deoptimized (reallocated and > > >> relocked), so we don't do it again > > >>> > > (relocking twice would be incorrect of course). Deferred updates > > are > > >> copied into the new > > >>> > > interpreter frames. > > >>> > > > > >>> > > Problem: relocking is not possible if the target thread T is waiting > > on the > > >> monitor that needs to > > >>> > > be relocked. This happens only with non-local objects with > > >> EliminateNestedLocks. Instead relocking > > >>> > > is deferred until T owns the monitor again. This is what the piece > of > > >> code above does. > > >>> > > > >>> > Sorry I need some more detail here. How can you wait() on an > > object > > >>> > monitor if the object allocation and/or locking was optimised > away? > > And > > >>> > what is a "non-local object" in this context? Isn't EA restricted to > > >>> > thread-confined objects? > > >>> > > >>> "Non-local object" is an object that escapes its thread. The issue I'm > > >> addressing with the changes > > >>> in ObjectMonitor::wait are almost unrelated to EA. They are caused by > > >> EliminateNestedLocks, where C2 > > >>> eliminates recursive locking of an already owned lock. The lock owning > > object > > >> exists on the heap, it > > >>> is locked and you can call wait() on it. > > >>> > > >>> EliminateLocks is the C2 option that controls lock elimination based on > > EA. > > >> Both optimizations have > > >>> in common that objects with eliminated locking need to be relocked > > when > > >> deoptimizing a frame, > > >>> i.e. when replacing a compiled frame with equivalent interpreter > > >>> frames. Deoptimization::relock_objects does that job for /all/ > eliminated > > >> locks in scope. /All/ can > > >>> be a mix of eliminated nested locks and locks of not-escaping objects. > > >>> > > >>> New with the enhancement: I call relock_objects earlier, just before > > objects > > >> pontentially > > >>> escape. But then later when the owning compiled frame gets > > deoptimized, I > > >> must not do it again: > > >>> > > >>> See call to EscapeBarrier::objs_are_deoptimized in > deoptimization.cpp: > > >>> > > >>> 373 if ((jvmci_enabled || ((DoEscapeAnalysis || > > EliminateNestedLocks) && > > >> EliminateLocks)) > > >>> 374 && !EscapeBarrier::objs_are_deoptimized(thread, > > deoptee.id())) { > > >>> 375 bool unused; > > >>> 376 eliminate_locks(thread, chunk, realloc_failures, deoptee, > > exec_mode, > > >> unused); > > >>> 377 } > > >>> > > >>> Now when calling relock_objects early it is quiet possible that I have to > > relock > > >> an object the > > >>> target thread currently waits for. Obviously I cannot relock in this case, > > >> instead I chose to > > >>> introduce relock_count_after_wait to JavaThread. > > >>> > > >>> > Is it just that some of the locking gets optimized away e.g. > > >>> > > > >>> > synchronised(obj) { > > >>> > synchronised(obj) { > > >>> > synchronised(obj) { > > >>> > obj.wait(); > > >>> > } > > >>> > } > > >>> > } > > >>> > > > >>> > If this is reduced to a form as-if it were a single lock of the monitor > > >>> > (due to EA) and the wait() triggers a JVM TI event which leads to > the > > >>> > escape of "obj" then we need to reconstruct the true lock state, > and > > so > > >>> > when the wait() internally unblocks and reacquires the monitor it > > has to > > >>> > set the true recursion count to 3, not the 1 that it appeared to be > > when > > >>> > wait() was initially called. Is that the scenario? > > >>> > > >>> Kind of... except that the locking is not eliminated due to EA and there > is > > no > > >> JVM TI event > > >>> triggered by wait. > > >>> > > >>> Add > > >>> > > >>> LocalObject l1 = new LocalObject(); > > >>> > > >>> in front of the synchrnized blocks and assume a JVM TI agent acquires > l1. > > This > > >> triggers the code in > > >>> question. > > >>> > > >>> See that relocking/reallocating is transactional. If it is done then for > /all/ > > >> objects in scope and it is > > >>> done at most once. It wouldn't be quite so easy to split this in relocking > > of > > >> nested/EA-based > > >>> eliminated locks. > > >>> > > >>> > If so I find this truly awful. Anyone using wait() in a realistic form > > >>> > requires a notification and so the object cannot be thread > confined. > > In > > >>> > > >>> It is not thread confined. > > >>> > > >>> > which case I would strongly argue that upon hitting the wait() the > > deopt > > >>> > should occur unconditionally and so the lock state is correct before > > we > > >>> > wait and so we don't need to mess with the recursion count > > internally > > >>> > when we reacquire the monitor. > > >>> > > > >>> > > > > >>> > > > which I don't like the sound of at all when it comes to > > ObjectMonitor > > >>> > > > state. So I'd like to understand in detail exactly what is going > on > > here > > >>> > > > and why. This is a very intrusive change that seems to badly > > break > > >>> > > > encapsulation and impacts future changes to ObjectMonitor > > that are > > >> under > > >>> > > > investigation. > > >>> > > > > >>> > > I would not regard this as breaking encapsulation. Certainly not > > badly. > > >>> > > > > >>> > > I've added a property relock_count_after_wait to JavaThread. > The > > >> property is well > > >>> > > encapsulated. Future ObjectMonitor implementations have to > deal > > with > > >> recursion too. They are free > > >>> > > in choosing a way to do that as long as that property is taken into > > >> account. This is hardly a > > >>> > > limitation. > > >>> > > > >>> > I do think this badly breaks encapsulation as you have to add a > > callout > > >>> > from the guts of the ObjectMonitor code to reach into the thread > to > > get > > >>> > this lock count adjustment. I understand why you have had to do > > this but > > >>> > I would much rather see a change to the EA optimisation strategy > so > > that > > >>> > this is not needed. > > >>> > > > >>> > > Note also that the property is a straight forward extension of the > > >> existing concept of deferred > > >>> > > local updates. It is embedded into the structure holding them. So > > not > > >> even the footprint of a > > >>> > > JavaThread is enlarged if no deferred updates are generated. > > >>> > > > >>> > [...] > > >>> > > > >>> > > > > >>> > > I'm actually duplicating the existing external suspend mechanism, > > >> because a thread can be > > >>> > > suspended at most once. And hey, and don't like that either! But > it > > >> seems not unlikely that the > > >>> > > duplicate can be removed together with the original and the new > > type > > >> of handshakes that will be > > >>> > > used for thread suspend can be used for object deoptimization > > too. See > > >> today's discussion in > > >>> > > JDK-8227745 [2]. > > >>> > > > >>> > I hope that discussion bears some fruit, at the moment it seems > not > > to > > >>> > be possible to use handshakes here. :( > > >>> > > > >>> > The external suspend mechanism is a royal pain in the proverbial > > that we > > >>> > have to carefully live with. The idea that we're duplicating that for > > >>> > use in another fringe area of functionality does not thrill me at all. > > >>> > > > >>> > To be clear, I understand the problem that exists and that you > wish > > to > > >>> > solve, but for the runtime parts I balk at the complexity cost of > > >>> > solving it. > > >>> > > >>> I know it's complex, but by far no rocket science. > > >>> > > >>> Also I find it hard to imagine another fix for JDK-8233915 besides > > changing > > >> the JVM TI specification. > > >>> > > >>> Thanks, Richard. > > >>> > > >>> -----Original Message----- > > >>> From: David Holmes > > >>> Sent: Dienstag, 17. Dezember 2019 08:03 > > >>> To: Reingruber, Richard ; serviceability- > > >> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; > > hotspot- > > >> runtime-dev at openjdk.java.net; Vladimir Kozlov > > (vladimir.kozlov at oracle.com) > > >> > > >>> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better > > Performance > > >> in the Presence of JVMTI Agents > > >>> > > >>> > > >>> > > >>> David > > >>> > > >>> On 17/12/2019 4:57 pm, David Holmes wrote: > > >>>> Hi Richard, > > >>>> > > >>>> On 14/12/2019 5:01 am, Reingruber, Richard wrote: > > >>>>> Hi David, > > >>>>> > > >>>>> ?? > Some further queries/concerns: > > >>>>> ?? > > > >>>>> ?? > src/hotspot/share/runtime/objectMonitor.cpp > > >>>>> ?? > > > >>>>> ?? > Can you please explain the changes to ObjectMonitor::wait: > > >>>>> ?? > > > >>>>> ?? > !?? _recursions = save????? // restore the old recursion count > > >>>>> ?? > !???????????????? + jt->get_and_reset_relock_count_after_wait(); // > > >>>>> ?? > increased by the deferred relock count > > >>>>> ?? > > > >>>>> ?? > what is the "deferred relock count"? I gather it relates to > > >>>>> ?? > > > >>>>> ?? > "The code was extended to be able to deoptimize objects of a > > >>>>> frame that > > >>>>> ?? > is not the top frame and to let another thread than the owning > > >>>>> thread do > > >>>>> ?? > it." > > >>>>> > > >>>>> Yes, these relate. Currently EA based optimizations are reverted, > > when > > >>>>> a compiled frame is replaced > > >>>>> with corresponding interpreter frames. Part of this is relocking > > >>>>> objects with eliminated > > >>>>> locking. New with the enhancement is that we do this also just > before > > >>>>> object references are acquired > > >>>>> through JVMTI. In this case we deoptimize also the owning compiled > > >>>>> frame C and we register > > >>>>> deoptimized objects as deferred updates. When control returns to > C > > it > > >>>>> gets deoptimized, we notice > > >>>>> that objects are already deoptimized (reallocated and relocked), so > > we > > >>>>> don't do it again (relocking > > >>>>> twice would be incorrect of course). Deferred updates are copied > into > > >>>>> the new interpreter frames. > > >>>>> > > >>>>> Problem: relocking is not possible if the target thread T is waiting > > >>>>> on the monitor that needs to be > > >>>>> relocked. This happens only with non-local objects with > > >>>>> EliminateNestedLocks. Instead relocking is > > >>>>> deferred until T owns the monitor again. This is what the piece of > > >>>>> code above does. > > >>>> > > >>>> Sorry I need some more detail here. How can you wait() on an object > > >>>> monitor if the object allocation and/or locking was optimised away? > > And > > >>>> what is a "non-local object" in this context? Isn't EA restricted to > > >>>> thread-confined objects? > > >>>> > > >>>> Is it just that some of the locking gets optimized away e.g. > > >>>> > > >>>> synchronised(obj) { > > >>>> ? synchronised(obj) { > > >>>> ??? synchronised(obj) { > > >>>> ????? obj.wait(); > > >>>> ??? } > > >>>> ? } > > >>>> } > > >>>> > > >>>> If this is reduced to a form as-if it were a single lock of the monitor > > >>>> (due to EA) and the wait() triggers a JVM TI event which leads to the > > >>>> escape of "obj" then we need to reconstruct the true lock state, and > so > > >>>> when the wait() internally unblocks and reacquires the monitor it has > to > > >>>> set the true recursion count to 3, not the 1 that it appeared to be > when > > >>>> wait() was initially called. Is that the scenario? > > >>>> > > >>>> If so I find this truly awful. Anyone using wait() in a realistic form > > >>>> requires a notification and so the object cannot be thread confined. > In > > >>>> which case I would strongly argue that upon hitting the wait() the > > deopt > > >>>> should occur unconditionally and so the lock state is correct before > we > > >>>> wait and so we don't need to mess with the recursion count internally > > >>>> when we reacquire the monitor. > > >>>> > > >>>>> > > >>>>> ?? > which I don't like the sound of at all when it comes to > > >>>>> ObjectMonitor > > >>>>> ?? > state. So I'd like to understand in detail exactly what is going > > >>>>> on here > > >>>>> ?? > and why.? This is a very intrusive change that seems to badly > > break > > >>>>> ?? > encapsulation and impacts future changes to ObjectMonitor > that > > >>>>> are under > > >>>>> ?? > investigation. > > >>>>> > > >>>>> I would not regard this as breaking encapsulation. Certainly not > badly. > > >>>>> > > >>>>> I've added a property relock_count_after_wait to JavaThread. The > > >>>>> property is well > > >>>>> encapsulated. Future ObjectMonitor implementations have to deal > > with > > >>>>> recursion too. They are free in > > >>>>> choosing a way to do that as long as that property is taken into > > >>>>> account. This is hardly a > > >>>>> limitation. > > >>>> > > >>>> I do think this badly breaks encapsulation as you have to add a callout > > >>>> from the guts of the ObjectMonitor code to reach into the thread to > > get > > >>>> this lock count adjustment. I understand why you have had to do this > > but > > >>>> I would much rather see a change to the EA optimisation strategy so > > that > > >>>> this is not needed. > > >>>> > > >>>>> Note also that the property is a straight forward extension of the > > >>>>> existing concept of deferred > > >>>>> local updates. It is embedded into the structure holding them. So > not > > >>>>> even the footprint of a > > >>>>> JavaThread is enlarged if no deferred updates are generated. > > >>>>> > > >>>>> ?? > --- > > >>>>> ?? > > > >>>>> ?? > src/hotspot/share/runtime/thread.cpp > > >>>>> ?? > > > >>>>> ?? > Can you please explain why > > >>>>> JavaThread::wait_for_object_deoptimization > > >>>>> ?? > has to be handcrafted in this way rather than using proper > > >>>>> transitions. > > >>>>> ?? > > > >>>>> > > >>>>> I wrote wait_for_object_deoptimization taking > > >>>>> JavaThread::java_suspend_self_with_safepoint_check > > >>>>> as template. So in short: for the same reasons :) > > >>>>> > > >>>>> Threads reach both methods as part of thread state transitions, > > >>>>> therefore special handling is > > >>>>> required to change thread state on top of ongoing transitions. > > >>>>> > > >>>>> ?? > We got rid of "deopt suspend" some time ago and it is > disturbing > > >>>>> to see > > >>>>> ?? > it being added back (effectively). This seems like it may be > > >>>>> something > > >>>>> ?? > that handshakes could be used for. > > >>>>> > > >>>>> Deopt suspend used to be something rather different with a similar > > >>>>> name[1]. It is not being added back. > > >>>> > > >>>> I stand corrected. Despite comments in the code to the contrary > > >>>> deopt_suspend didn't actually cause a self-suspend. I was doing a lot > of > > >>>> cleanup in this area 13 years ago :) > > >>>> > > >>>>> > > >>>>> I'm actually duplicating the existing external suspend mechanism, > > >>>>> because a thread can be suspended > > >>>>> at most once. And hey, and don't like that either! But it seems not > > >>>>> unlikely that the duplicate can > > >>>>> be removed together with the original and the new type of > > handshakes > > >>>>> that will be used for > > >>>>> thread suspend can be used for object deoptimization too. See > > today's > > >>>>> discussion in JDK-8227745 [2]. > > >>>> > > >>>> I hope that discussion bears some fruit, at the moment it seems not > to > > >>>> be possible to use handshakes here. :( > > >>>> > > >>>> The external suspend mechanism is a royal pain in the proverbial that > > we > > >>>> have to carefully live with. The idea that we're duplicating that for > > >>>> use in another fringe area of functionality does not thrill me at all. > > >>>> > > >>>> To be clear, I understand the problem that exists and that you wish to > > >>>> solve, but for the runtime parts I balk at the complexity cost of > > >>>> solving it. > > >>>> > > >>>> Thanks, > > >>>> David > > >>>> ----- > > >>>> > > >>>>> Thanks, Richard. > > >>>>> > > >>>>> [1] Deopt suspend was something like an async. handshake for > > >>>>> architectures with register windows, > > >>>>> ???? where patching the return pc for deoptimization of a compiled > > >>>>> frame was racy if the owner thread > > >>>>> ???? was in native code. Instead a "deopt" suspend flag was set on > > >>>>> which the thread patched its own > > >>>>> ???? frame upon return from native. So no thread was suspended. It > > got > > >>>>> its name only from the name of > > >>>>> ???? the flags. > > >>>>> > > >>>>> [2] Discussion about using handshakes to sync. with the target > thread: > > >>>>> > > >>>>> https://bugs.openjdk.java.net/browse/JDK- > > >> > > > 8227745?focusedCommentId=14306727&page=com.atlassian.jira.plugin.syst > > e > > >> m.issuetabpanels:comment-tabpanel#comment-14306727 > > >>>>> > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: David Holmes > > >>>>> Sent: Freitag, 13. Dezember 2019 00:56 > > >>>>> To: Reingruber, Richard ; > > >>>>> serviceability-dev at openjdk.java.net; > > >>>>> hotspot-compiler-dev at openjdk.java.net; > > >>>>> hotspot-runtime-dev at openjdk.java.net > > >>>>> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better > > >>>>> Performance in the Presence of JVMTI Agents > > >>>>> > > >>>>> Hi Richard, > > >>>>> > > >>>>> Some further queries/concerns: > > >>>>> > > >>>>> src/hotspot/share/runtime/objectMonitor.cpp > > >>>>> > > >>>>> Can you please explain the changes to ObjectMonitor::wait: > > >>>>> > > >>>>> !?? _recursions = save????? // restore the old recursion count > > >>>>> !???????????????? + jt->get_and_reset_relock_count_after_wait(); // > > >>>>> increased by the deferred relock count > > >>>>> > > >>>>> what is the "deferred relock count"? I gather it relates to > > >>>>> > > >>>>> "The code was extended to be able to deoptimize objects of a > frame > > that > > >>>>> is not the top frame and to let another thread than the owning > thread > > do > > >>>>> it." > > >>>>> > > >>>>> which I don't like the sound of at all when it comes to ObjectMonitor > > >>>>> state. So I'd like to understand in detail exactly what is going on here > > >>>>> and why.? This is a very intrusive change that seems to badly break > > >>>>> encapsulation and impacts future changes to ObjectMonitor that > are > > under > > >>>>> investigation. > > >>>>> > > >>>>> --- > > >>>>> > > >>>>> src/hotspot/share/runtime/thread.cpp > > >>>>> > > >>>>> Can you please explain why > > JavaThread::wait_for_object_deoptimization > > >>>>> has to be handcrafted in this way rather than using proper > transitions. > > >>>>> > > >>>>> We got rid of "deopt suspend" some time ago and it is disturbing to > > see > > >>>>> it being added back (effectively). This seems like it may be > something > > >>>>> that handshakes could be used for. > > >>>>> > > >>>>> Thanks, > > >>>>> David > > >>>>> ----- > > >>>>> > > >>>>> On 12/12/2019 7:02 am, David Holmes wrote: > > >>>>>> On 12/12/2019 1:07 am, Reingruber, Richard wrote: > > >>>>>>> Hi David, > > >>>>>>> > > >>>>>>> ??? > Most of the details here are in areas I can comment on in > > detail, > > >>>>>>> but I > > >>>>>>> ??? > did take an initial general look at things. > > >>>>>>> > > >>>>>>> Thanks for taking the time! > > >>>>>> > > >>>>>> Apologies the above should read: > > >>>>>> > > >>>>>> "Most of the details here are in areas I *can't* comment on in > detail > > >>>>>> ..." > > >>>>>> > > >>>>>> David > > >>>>>> > > >>>>>>> ??? > The only thing that jumped out at me is that I think the > > >>>>>>> ??? > DeoptimizeObjectsALotThread should be a hidden thread. > > >>>>>>> ??? > > > >>>>>>> ??? > +? bool is_hidden_from_external_view() const { return true; > } > > >>>>>>> > > >>>>>>> Yes, it should. Will add the method like above. > > >>>>>>> > > >>>>>>> ??? > Also I don't see any testing of the > > DeoptimizeObjectsALotThread. > > >>>>>>> Without > > >>>>>>> ??? > active testing this will just bit-rot. > > >>>>>>> > > >>>>>>> DeoptimizeObjectsALot is meant for stress testing with a larger > > >>>>>>> workload. I will add a minimal test > > >>>>>>> to keep it fresh. > > >>>>>>> > > >>>>>>> ??? > Also on the tests I don't understand your @requires clause: > > >>>>>>> ??? > > > >>>>>>> ??? >?? @requires ((vm.compMode != "Xcomp") & > > vm.compiler2.enabled > > >> & > > >>>>>>> ??? > (vm.opt.TieredCompilation != true)) > > >>>>>>> ??? > > > >>>>>>> ??? > This seems to require that TieredCompilation is disabled, but > > >>>>>>> tiered is > > >>>>>>> ??? > our normal mode of operation. ?? > > >>>>>>> ??? > > > >>>>>>> > > >>>>>>> I removed the clause. I guess I wanted to target the tests towards > > the > > >>>>>>> code they are supposed to > > >>>>>>> test, and it's easier to analyze failures w/o tiered compilation and > > >>>>>>> with just one compiler thread. > > >>>>>>> > > >>>>>>> Additionally I will make use of > > >>>>>>> compiler.whitebox.CompilerWhiteBoxTest.THRESHOLD in the > tests. > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> Richard. > > >>>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: David Holmes > > >>>>>>> Sent: Mittwoch, 11. Dezember 2019 08:03 > > >>>>>>> To: Reingruber, Richard ; > > >>>>>>> serviceability-dev at openjdk.java.net; > > >>>>>>> hotspot-compiler-dev at openjdk.java.net; > > >>>>>>> hotspot-runtime-dev at openjdk.java.net > > >>>>>>> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better > > >>>>>>> Performance in the Presence of JVMTI Agents > > >>>>>>> > > >>>>>>> Hi Richard, > > >>>>>>> > > >>>>>>> On 11/12/2019 7:45 am, Reingruber, Richard wrote: > > >>>>>>>> Hi, > > >>>>>>>> > > >>>>>>>> I would like to get reviews please for > > >>>>>>>> > > >>>>>>>> > > http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/ > > >>>>>>>> > > >>>>>>>> Corresponding RFE: > > >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8227745 > > >>>>>>>> > > >>>>>>>> Fixes also https://bugs.openjdk.java.net/browse/JDK-8233915 > > >>>>>>>> And potentially https://bugs.openjdk.java.net/browse/JDK- > > 8214584 [1] > > >>>>>>>> > > >>>>>>>> Vladimir Kozlov kindly put webrev.3 through tier1-8 testing > > without > > >>>>>>>> issues (thanks!). In addition the > > >>>>>>>> change is being tested at SAP since I posted the first RFR some > > >>>>>>>> months ago. > > >>>>>>>> > > >>>>>>>> The intention of this enhancement is to benefit performance > wise > > from > > >>>>>>>> escape analysis even if JVMTI > > >>>>>>>> agents request capabilities that allow them to access local > variable > > >>>>>>>> values. E.g. if you start-up > > >>>>>>>> with -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, > > then > > >>>>>>>> escape analysis is disabled right > > >>>>>>>> from the beginning, well before a debugger attaches -- if ever > one > > >>>>>>>> should do so. With the > > >>>>>>>> enhancement, escape analysis will remain enabled until and > after > > a > > >>>>>>>> debugger attaches. EA based > > >>>>>>>> optimizations are reverted just before an agent acquires the > > >>>>>>>> reference to an object. In the JBS item > > >>>>>>>> you'll find more details. > > >>>>>>> > > >>>>>>> Most of the details here are in areas I can comment on in detail, > but > > I > > >>>>>>> did take an initial general look at things. > > >>>>>>> > > >>>>>>> The only thing that jumped out at me is that I think the > > >>>>>>> DeoptimizeObjectsALotThread should be a hidden thread. > > >>>>>>> > > >>>>>>> +? bool is_hidden_from_external_view() const { return true; } > > >>>>>>> > > >>>>>>> Also I don't see any testing of the DeoptimizeObjectsALotThread. > > >>>>>>> Without > > >>>>>>> active testing this will just bit-rot. > > >>>>>>> > > >>>>>>> Also on the tests I don't understand your @requires clause: > > >>>>>>> > > >>>>>>> ??? @requires ((vm.compMode != "Xcomp") & > > vm.compiler2.enabled & > > >>>>>>> (vm.opt.TieredCompilation != true)) > > >>>>>>> > > >>>>>>> This seems to require that TieredCompilation is disabled, but > tiered > > is > > >>>>>>> our normal mode of operation. ?? > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> David > > >>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> Richard. > > >>>>>>>> > > >>>>>>>> [1] Experimental fix for JDK-8214584 based on JDK-8227745 > > >>>>>>>> > > >> > > > http://cr.openjdk.java.net/~rrich/webrevs/2019/8214584/experiment_v1.pa > > tc > > >> h > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> From richard.reingruber at sap.com Wed Apr 1 06:19:10 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 1 Apr 2020 06:19:10 +0000 Subject: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: <0a07f87e-ede1-edbd-c754-e7df884e0545@oracle.com> References: <1f8a3c7a-fa0f-b5b2-4a8a-7d3d8dbbe1b5@oracle.com> <4b56a45c-a14c-6f74-2bfd-25deaabe8201@oracle.com> <5271429a-481d-ddb9-99dc-b3f6670fcc0b@oracle.com> <0a07f87e-ede1-edbd-c754-e7df884e0545@oracle.com> Message-ID: > Thanks for cleaning up thread.hpp! Thanks for providing the feedback! I justed noticed that the forward declaration of class jvmtiDeferredLocalVariableSet is not required anymore. Will remove it in the next webrev. Hope to get some more (partial) reviews. Thanks, Richard. -----Original Message----- From: Robbin Ehn Sent: Dienstag, 31. M?rz 2020 16:21 To: Reingruber, Richard ; Doerr, Martin ; Lindenmaier, Goetz ; David Holmes ; Vladimir Kozlov (vladimir.kozlov at oracle.com) ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Thanks for cleaning up thread.hpp! /Robbin On 2020-03-30 10:31, Reingruber, Richard wrote: > Hi, > > this is webrev.5 based on Robbin's feedback and Martin's review - thanks! :) > > The change affects jvmti, hotspot and c2. Partial reviews are very welcome too. > > Full: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.5/ > Delta: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.5.inc/ > > Robbin, Martin, please let me know, if anything shouldn't be quite as you wanted it. Also find my > comments on your feedback below. > > Robbin, can I count you as Reviewer for the runtime part? > > Thanks, Richard. > > -- > >> DeoptimizeObjectsALotThread is only used in compileBroker.cpp. >> You can move both declaration and definition to that file, no need to clobber >> thread.[c|h]pp. (and the static function deopt_objs_alot_thread_entry) > > Done. > >> Does JvmtiDeferredUpdates really need to be in thread.hpp, can't be in it's own >> hpp file? It doesn't seem right to add JVM TI classes into thread.hpp. > > I moved JvmtiDeferredUpdates to vframe_hp.hpp where preexisting jvmtiDeferredLocalVariableSet is > declared. > >> src/hotspot/share/code/compiledMethod.cpp >> Nice cleanup! > > Thanks :) > >> src/hotspot/share/code/debugInfoRec.cpp >> src/hotspot/share/code/debugInfoRec.hpp >> Additional parmeters. (Remark: I think "non_global_escape_in_scope" would read better than "not_global_escape_in_scope", but your version is consistent with existing code, so no change request from my side.) Ok. > > I've been thinking about this too and finally stayed with not_global_escape_in_scope. It's supposed > to mean an object whose escape state is not GlobalEscape is in scope. > >> src/hotspot/share/compiler/compileBroker.cpp >> src/hotspot/share/compiler/compileBroker.hpp >> Extra thread for DeoptimizeObjectsALot. (Remark: I would have put it into a follow up change together with the test in order to make this webrev smaller, but since it is included, I'm reviewing everything at once. Not a big deal.) Ok. > > Yes the change would be a little smaller. And if it helps I'll split it off. In general I prefer > patches that bring along a suitable amount of tests. > >> src/hotspot/share/opto/c2compiler.cpp >> Make do_escape_analysis independent of JVMCI capabilities. Nice! > > It is the main goal of the enhancement. It is done for C2, but could be done for JVMCI compilers > with just a small effort as well. > >> src/hotspot/share/opto/escape.cpp >> Annotation for MachSafePointNodes. Your added functionality looks correct. >> But I'd prefer to move the bulky code out of the large function. >> I suggest to factor out something like has_not_global_escape and has_arg_escape. So the code could look like this: >> SafePointNode* sfn = sfn_worklist.at(next); >> sfn->set_not_global_escape_in_scope(has_not_global_escape(sfn)); >> if (sfn->is_CallJava()) { >> CallJavaNode* call = sfn->as_CallJava(); >> call->set_arg_escape(has_arg_escape(call)); >> } >> This would also allow us to get rid of the found_..._escape_in_args variables making the loops better readable. > > Done. > >> It's kind of ugly to use strcmp to recognize uncommon trap, but that seems to be the way to do it (there are more such places). So it's ok. > > Yeah. I copied the snippet. > >> src/hotspot/share/prims/jvmtiImpl.cpp >> src/hotspot/share/prims/jvmtiImpl.hpp >> The sequence is pretty complex: >> VM_GetOrSetLocal element initialization executes EscapeBarrier code which suspends the target thread (extra VM Operation). > > Note that the target threads have to be suspended already for VM_GetOrSetLocal*. So it's mainly the > synchronization effect of EscapeBarrier::sync_and_suspend_one() that is required here. Also no extra > _handshake_ is executed, since sync_and_suspend_one() will find the target threads already > suspended. > >> VM_GetOrSetLocal::doit_prologue performs object deoptimization (by VM Thread to prepare VM Operation with frame deoptimization). >> VM_GetOrSetLocal destructor implicitly calls EscapeBarrier destructor which resumes the target thread. >> But I don't have any improvement proposal. Performance is probably not a concern, here. So it's ok. > >> VM_GetOrSetLocal::deoptimize_objects deoptimizes the top frame if it has non-globally escaping objects and other frames if they have arg escaping ones. Good. > > It's not specifically the top frame, but the frame that is accessed. > >> src/hotspot/share/runtime/deoptimization.cpp >> Object deoptimization. I have more comments and proposals, here. >> First of all, handling recursive and waiting locks in relock_objects is tricky, but looks correct. >> Comments are sufficient to understand why things are done as they are implemented. > >> BiasedLocking related parts are complex, but we may get rid of them in the future (with BiasedLocking removal). >> Anyway, looks correct, too. > >> Typo in comment: "regularily" => "regularly" > >> Deoptimization::fetch_unroll_info_helper is the only place where _jvmti_deferred_updates get deallocated (except JavaThread destructor). But I think we always go through it, so I can't see a memory leak or such kind of issues. > > That's correct. The compiled frame for which deferred updates are allocated is always deoptimized > before (see EscapeBarrier::deoptimize_objects()). This is also asserted in > compiledVFrame::update_deferred_value(). I've added the same assertion to > Deoptimization::relock_objects(). So we can be sure that _jvmti_deferred_updates are deallocated > again in fetch_unroll_info_helper(). > >> EscapeBarrier::deoptimize_objects: ResourceMark should use calling_thread(). > > Sure, well spotted! > >> You can use MutexLocker and MonitorLocker with Thread* to save the Thread::current() call. > > Right, good hint. This was recently introduced with 8235678. I even had to resolve conflicts. Should > have done this then. > >> I'd make set_objs_are_deoptimized static and remove it from the EscapeBarrier interface because I think it shouldn't be used outside of EscapeBarrier::deoptimize_objects. > > Done. > >> Typo in comment: "we must only deoptimize" => "we only have to deoptimize" > > Replaced with "[...] we deoptimize iff local objects are passed as args" > >> "bool EscapeBarrier::deoptimize_objects(intptr_t* fr_id)" is trivial and barrier_active() is redundant. Implementation can get moved to hpp file. > > Ok. Done. > >> I'll get back to suspend flags, later. > >> There are weird cases regarding _self_deoptimization_in_progress. >> Assume we have 3 threads A, B and C. A deopts C, B deopts C, C deopts C. C can set _self_deoptimization_in_progress while A performs the handshake for suspending C. I think this doesn't lead to errors, but it's probably not desired. >> I think it would be better to use only one "wait" call in sync_and_suspend_one and sync_and_suspend_all. > > You're right. We've discussed that face-to-face, but couldn't find a real issue. But now, thinking again, a reckon I found one: > > 2808 // Sync with other threads that might be doing deoptimizations > 2809 { > 2810 // Need to switch to _thread_blocked for the wait() call > 2811 ThreadBlockInVM tbivm(_calling_thread); > 2812 MonitorLocker ml(EscapeBarrier_lock, Mutex::_no_safepoint_check_flag); > 2813 while (_self_deoptimization_in_progress) { > 2814 ml.wait(); > 2815 } > 2816 > 2817 if (self_deopt()) { > 2818 _self_deoptimization_in_progress = true; > 2819 } > 2820 > 2821 while (_deoptee_thread->is_ea_obj_deopt_suspend()) { > 2822 ml.wait(); > 2823 } > 2824 > 2825 if (self_deopt()) { > 2826 return; > 2827 } > 2828 > 2829 // set suspend flag for target thread > 2830 _deoptee_thread->set_ea_obj_deopt_flag(); > 2831 } > > - A waits in 2822 > - C is suspended > - B notifies all in resume_one() > - A and C wake up > - C wins over A and sets _self_deoptimization_in_progress = true in 2818 > - C does the self deoptimization > - A executes 2830 _deoptee_thread->set_ea_obj_deopt_flag() > > C will self suspend at some undefined point. The resulting state is illegal. > >> I first thought it'd be better to move ThreadBlockInVM before wait() to reduce thread state transitions, but that seems to be problematic because ThreadBlockInVM destructor contains a safepoint check which we shouldn't do while holding EscapeBarrier_lock. So no change request. > > Yes, would be nice to have the state change only if needed, but for the reason you mentioned it is > not quite as easy as it seems to be. I experimented as well with a second lock, but did not succeed. > >> Change in thred_added: >> I think the sequence would be more comprehensive if we waited for deopt_all_threads in Thread::start and all other places where a new thread can run into Java code (e.g. JVMTI attach). >> Your version makes new threads come up with suspend flag set. That looks correct, too. Advantage is that you only have to change one place (thread_added). It'll be interesting to see how it will look like when we use async handshakes instead of suspend flags. >> For now, I'm ok with your version. > > I had a version that did what you are suggesting. The current version also has the advantage, that > there are fewer places where a thread has to wait for ongoing object deoptimization. This means > viewer places where you have to worry about correct thread state transitions, possible deadlocks, > and if all oops are properly Handle'ed. > >> I'd only move MutexLocker ml(EscapeBarrier_lock...) after if (!jt->is_hidden_from_external_view()). > > Done. > >> Having 4 different deoptimize_objects functions makes it a little hard to keep an overview of which one is used for what. >> Maybe adding suffixes would help a little bit, but I can also live with what you have. >> Implementation looks correct to me. > > 2 are internal. I added the suffix _internal to them. This leaves 2 to choose from. > >> src/hotspot/share/runtime/deoptimization.hpp >> Escape barriers and object deoptimization functions. >> Typo in comment: "helt" => "held" > > Done in place already. > >> src/hotspot/share/runtime/interfaceSupport.cpp >> InterfaceSupport::deoptimizeAllObjects() is only used for DeoptimizeObjectsALot = 1. >> I think DeoptimizeObjectsALot = 2 is more important, but I think it's not bad to have DeoptimizeObjectsALot = 1 in addition. Ok. > > I never used DeoptimizeObjectsALot = 1 that much. It could be more deterministic in single threaded > scenarios. I wouldn't object to get rid of it though. > >> src/hotspot/share/runtime/stackValue.hpp >> Better reinitilization in StackValue. Good. > > StackValue::obj_is_scalar_replaced() should not return true after calling set_obj(). > >> src/hotspot/share/runtime/thread.cpp >> src/hotspot/share/runtime/thread.hpp >> src/hotspot/share/runtime/thread.inline.hpp >> wait_for_object_deoptimization, suspend flag, deferred updates and test feature to deoptimize objects. > >> In the long term, we want to get rid of suspend flags, so it's not so nice to introduce a new one. But I agree with G?tz that it should be acceptable as temporary solution until async handshakes are available (which takes more time). So I'm ok with your change. > > I'm keen to build the feature on async handshakes when the arive. > >> You can use MutexLocker with Thread*. > > Done. > >> JVMTIDeferredUpdates: I agree with Robin. It'd be nice to move the class out of thread.hpp. > > Done. > >> src/hotspot/share/runtime/vframe.cpp >> Added support for entry frame to new_vframe. Ok. > > >> src/hotspot/share/runtime/vframe_hp.cpp >> src/hotspot/share/runtime/vframe_hp.hpp > >> I think code()->as_nmethod() in not_global_escape_in_scope() and arg_escape() should better be under #ifdef ASSERT or inside the assert statement (no need for code cache walking in product build). > > Done. > >> jvmtiDeferredLocalVariableSet::update_monitors: >> Please add a comment explaining that owner referenced by original info may be scalar replaced, but it is deoptimized in the vframe. > > Done. > > -----Original Message----- > From: Doerr, Martin > Sent: Donnerstag, 12. M?rz 2020 17:28 > To: Reingruber, Richard ; 'Robbin Ehn' ; Lindenmaier, Goetz ; David Holmes ; Vladimir Kozlov (vladimir.kozlov at oracle.com) ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents > > Hi Richard, > > > I managed to find time for a (almost) complete review of webrev.4. (I'll review the tests separately.) > > First of all, the change seems to be in pretty good quality for its significant complexity. I couldn't find any real bugs. But I'd like to propose minor improvements. > I'm convinced that it's mature because we did substantial testing. > > I like the new functionality for object deoptimization. It can possibly be reused for future escape analysis based optimizations. So I appreciate having it available in the code base. > In addition to that, your change makes the JVMTI implementation better integrated into the VM. > > > Now to the details: > > > src/hotspot/share/c1/c1_IR.hpp > describe_scope parameters. Ok. > > > src/hotspot/share/ci/ciEnv.cpp > src/hotspot/share/ci/ciEnv.hpp > Fix for JvmtiExport::can_walk_any_space() capability. Ok. > > > src/hotspot/share/code/compiledMethod.cpp > Nice cleanup! > > > src/hotspot/share/code/debugInfoRec.cpp > src/hotspot/share/code/debugInfoRec.hpp > Additional parmeters. (Remark: I think "non_global_escape_in_scope" would read better than "not_global_escape_in_scope", but your version is consistent with existing code, so no change request from my side.) Ok. > > > src/hotspot/share/code/nmethod.cpp > Nice cleanup! > > > src/hotspot/share/code/pcDesc.hpp > Additional parameters. Ok. > > > src/hotspot/share/code/scopeDesc.cpp > src/hotspot/share/code/scopeDesc.hpp > Improved implementation + additional parameters. Ok. > > > src/hotspot/share/compiler/compileBroker.cpp > src/hotspot/share/compiler/compileBroker.hpp > Extra thread for DeoptimizeObjectsALot. (Remark: I would have put it into a follow up change together with the test in order to make this webrev smaller, but since it is included, I'm reviewing everything at once. Not a big deal.) Ok. > > > src/hotspot/share/jvmci/jvmciCodeInstaller.cpp > Additional parameters. Ok. > > > src/hotspot/share/opto/c2compiler.cpp > Make do_escape_analysis independent of JVMCI capabilities. Nice! > > > src/hotspot/share/opto/callnode.hpp > Additional fields for MachSafePointNodes. Ok. > > > src/hotspot/share/opto/escape.cpp > Annotation for MachSafePointNodes. Your added functionality looks correct. > But I'd prefer to move the bulky code out of the large function. > I suggest to factor out something like has_not_global_escape and has_arg_escape. So the code could look like this: > SafePointNode* sfn = sfn_worklist.at(next); > sfn->set_not_global_escape_in_scope(has_not_global_escape(sfn)); > if (sfn->is_CallJava()) { > CallJavaNode* call = sfn->as_CallJava(); > call->set_arg_escape(has_arg_escape(call)); > } > This would also allow us to get rid of the found_..._escape_in_args variables making the loops better readable. > > It's kind of ugly to use strcmp to recognize uncommon trap, but that seems to be the way to do it (there are more such places). So it's ok. > > > src/hotspot/share/opto/machnode.hpp > Additional fields for MachSafePointNodes. Ok. > > > src/hotspot/share/opto/macro.cpp > Allow elimination of non-escaping allocations. Ok. > > > src/hotspot/share/opto/matcher.cpp > src/hotspot/share/opto/output.cpp > Copy attribute / pass parameters. Ok. > > > src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp > Nice cleanup! > > > src/hotspot/share/prims/jvmtiEnv.cpp > src/hotspot/share/prims/jvmtiEnvBase.cpp > Escape barriers + deoptimize objects for target thread. Good. > > > src/hotspot/share/prims/jvmtiImpl.cpp > src/hotspot/share/prims/jvmtiImpl.hpp > The sequence is pretty complex: > VM_GetOrSetLocal element initialization executes EscapeBarrier code which suspends the target thread (extra VM Operation). > VM_GetOrSetLocal::doit_prologue performs object deoptimization (by VM Thread to prepare VM Operation with frame deoptimization). > VM_GetOrSetLocal destructor implicitly calls EscapeBarrier destructor which resumes the target thread. > But I don't have any improvement proposal. Performance is probably not a concern, here. So it's ok. > > VM_GetOrSetLocal::deoptimize_objects deoptimizes the top frame if it has non-globally escaping objects and other frames if they have arg escaping ones. Good. > > > src/hotspot/share/prims/jvmtiTagMap.cpp > Escape barriers + deoptimize objects for all threads. Ok. > > > src/hotspot/share/prims/whitebox.cpp > Added WB_IsFrameDeoptimized to API. Ok. > > > src/hotspot/share/runtime/deoptimization.cpp > Object deoptimization. I have more comments and proposals, here. > First of all, handling recursive and waiting locks in relock_objects is tricky, but looks correct. > Comments are sufficient to understand why things are done as they are implemented. > > BiasedLocking related parts are complex, but we may get rid of them in the future (with BiasedLocking removal). > Anyway, looks correct, too. > > Typo in comment: "regularily" => "regularly" > > Deoptimization::fetch_unroll_info_helper is the only place where _jvmti_deferred_updates get deallocated (except JavaThread destructor). But I think we always go through it, so I can't see a memory leak or such kind of issues. > > EscapeBarrier::deoptimize_objects: ResourceMark should use calling_thread(). > > You can use MutexLocker and MonitorLocker with Thread* to save the Thread::current() call. > > I'd make set_objs_are_deoptimized static and remove it from the EscapeBarrier interface because I think it shouldn't be used outside of EscapeBarrier::deoptimize_objects. > > Typo in comment: "we must only deoptimize" => "we only have to deoptimize" > > "bool EscapeBarrier::deoptimize_objects(intptr_t* fr_id)" is trivial and barrier_active() is redundant. Implementation can get moved to hpp file. > > I'll get back to suspend flags, later. > > There are weird cases regarding _self_deoptimization_in_progress. > Assume we have 3 threads A, B and C. A deopts C, B deopts C, C deopts C. C can set _self_deoptimization_in_progress while A performs the handshake for suspending C. I think this doesn't lead to errors, but it's probably not desired. > I think it would be better to use only one "wait" call in sync_and_suspend_one and sync_and_suspend_all. > > I first thought it'd be better to move ThreadBlockInVM before wait() to reduce thread state transitions, but that seems to be problematic because ThreadBlockInVM destructor contains a safepoint check which we shouldn't do while holding EscapeBarrier_lock. So no change request. > > Change in thred_added: > I think the sequence would be more comprehensive if we waited for deopt_all_threads in Thread::start and all other places where a new thread can run into Java code (e.g. JVMTI attach). > Your version makes new threads come up with suspend flag set. That looks correct, too. Advantage is that you only have to change one place (thread_added). It'll be interesting to see how it will look like when we use async handshakes instead of suspend flags. > For now, I'm ok with your version. > > I'd only move MutexLocker ml(EscapeBarrier_lock...) after if (!jt->is_hidden_from_external_view()). > > Having 4 different deoptimize_objects functions makes it a little hard to keep an overview of which one is used for what. > Maybe adding suffixes would help a little bit, but I can also live with what you have. > Implementation looks correct to me. > > > src/hotspot/share/runtime/deoptimization.hpp > Escape barriers and object deoptimization functions. > Typo in comment: "helt" => "held" > > > src/hotspot/share/runtime/globals.hpp > Addition of develop flag DeoptimizeObjectsALotInterval. Ok. > > > src/hotspot/share/runtime/interfaceSupport.cpp > InterfaceSupport::deoptimizeAllObjects() is only used for DeoptimizeObjectsALot = 1. > I think DeoptimizeObjectsALot = 2 is more important, but I think it's not bad to have DeoptimizeObjectsALot = 1 in addition. Ok. > > > src/hotspot/share/runtime/interfaceSupport.inline.hpp > Addition of deoptimizeAllObjects. Ok. > > > src/hotspot/share/runtime/mutexLocker.cpp > src/hotspot/share/runtime/mutexLocker.hpp > Addition of EscapeBarrier_lock. Ok. > > > src/hotspot/share/runtime/objectMonitor.cpp > Make recursion count relock aware. Ok. > > > src/hotspot/share/runtime/stackValue.hpp > Better reinitilization in StackValue. Good. > > > src/hotspot/share/runtime/thread.cpp > src/hotspot/share/runtime/thread.hpp > src/hotspot/share/runtime/thread.inline.hpp > wait_for_object_deoptimization, suspend flag, deferred updates and test feature to deoptimize objects. > > In the long term, we want to get rid of suspend flags, so it's not so nice to introduce a new one. But I agree with G?tz that it should be acceptable as temporary solution until async handshakes are available (which takes more time). So I'm ok with your change. > > You can use MutexLocker with Thread*. > > JVMTIDeferredUpdates: I agree with Robin. It'd be nice to move the class out of thread.hpp. > > > src/hotspot/share/runtime/vframe.cpp > Added support for entry frame to new_vframe. Ok. > > > src/hotspot/share/runtime/vframe_hp.cpp > src/hotspot/share/runtime/vframe_hp.hpp > > I think code()->as_nmethod() in not_global_escape_in_scope() and arg_escape() should better be under #ifdef ASSERT or inside the assert statement (no need for code cache walking in product build). > > jvmtiDeferredLocalVariableSet::update_monitors: > Please add a comment explaining that owner referenced by original info may be scalar replaced, but it is deoptimized in the vframe. > > > src/hotspot/share/utilities/macros.hpp > Addition of NOT_COMPILER2_OR_JVMCI_RETURN macros. Ok. > > > test/hotspot/jtreg/serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java > test/hotspot/jtreg/serviceability/jvmti/Heap/libIterateHeapWithEscapeAnalysisEnabled.c > New test. Will review separately. > > > test/jdk/TEST.ROOT > Addition of vm.jvmci as required property. Ok. > > > test/jdk/com/sun/jdi/EATests.java > test/jdk/com/sun/jdi/EATestsJVMCI.java > New test. Will review separately. > > > test/lib/sun/hotspot/WhiteBox.java > Added isFrameDeoptimized to API. Ok. > > > That was it. Best regards, > Martin > > >> -----Original Message----- >> From: hotspot-compiler-dev > bounces at openjdk.java.net> On Behalf Of Reingruber, Richard >> Sent: Dienstag, 3. M?rz 2020 21:23 >> To: 'Robbin Ehn' ; Lindenmaier, Goetz >> ; David Holmes ; >> Vladimir Kozlov (vladimir.kozlov at oracle.com) >> ; serviceability-dev at openjdk.java.net; >> hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better >> Performance in the Presence of JVMTI Agents >> >> Hi Robbin, >> >>>> I understand that Robbin proposed to replace the usage of >>>> _suspend_flag with handshakes. Apparently, async handshakes >>>> are needed to do so. We have been waiting a while for removal >>>> of the _suspend_flag / introduction of async handshakes [2]. >>>> What is the status here? >> >>> I have an old prototype which I would like to continue to work on. >>> So do not assume asynch handshakes will make 15. >>> Even if it would, I think there are a lot more investigate work to remove >>> _suspend_flag. >> >> Let us know, if we can be of any help to you and be it only testing. >> >>>>> Full: >> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4/ >> >>> DeoptimizeObjectsALotThread is only used in compileBroker.cpp. >>> You can move both declaration and definition to that file, no need to >> clobber >>> thread.[c|h]pp. (and the static function deopt_objs_alot_thread_entry) >> >> Will do. >> >>> Does JvmtiDeferredUpdates really need to be in thread.hpp, can't be in it's >> own >>> hpp file? It doesn't seem right to add JVM TI classes into thread.hpp. >> >> You are right. It shouldn't be declared in thread.hpp. I will look into that. >> >>> Note that we also think we may have a bug in deopt: >>> https://bugs.openjdk.java.net/browse/JDK-8238237 >> >>> I think it would be best, if possible, to push after that is resolved. >> >> Sure. >> >>> Not even nearly a full review :) >> >> I know :) >> >> Anyways, thanks a lot, >> Richard. >> >> >> -----Original Message----- >> From: Robbin Ehn >> Sent: Monday, March 2, 2020 11:17 AM >> To: Lindenmaier, Goetz ; Reingruber, Richard >> ; David Holmes ; >> Vladimir Kozlov (vladimir.kozlov at oracle.com) >> ; serviceability-dev at openjdk.java.net; >> hotspot-compiler-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance >> in the Presence of JVMTI Agents >> >> Hi, >> >> On 2/24/20 5:39 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I had a look at the progress of this change. Nothing >>> happened since Richard posted his update using more >>> handshakes [1]. >>> But we (SAP) would appreciate a lot if this change could >>> be successfully reviewed and pushed. >>> >>> I think there is basic understanding that this >>> change is helpful. It fixes a number of issues with JVMTI, >>> and will deliver the same performance benefits as EA >>> does in current production mode for debugging scenarios. >>> >>> This is important for us as we run our VMs prepared >>> for debugging in production mode. >>> >>> I understand that Robbin proposed to replace the usage of >>> _suspend_flag with handshakes. Apparently, async handshakes >>> are needed to do so. We have been waiting a while for removal >>> of the _suspend_flag / introduction of async handshakes [2]. >>> What is the status here? >> >> I have an old prototype which I would like to continue to work on. >> So do not assume asynch handshakes will make 15. >> Even if it would, I think there are a lot more investigate work to remove >> _suspend_flag. >> >>> >>> I think we should no longer wait, but proceed with >>> this change. We will look into removing the usage of >>> suspend_flag introduced here once it is possible to implement >>> it with handshakes. >> >> Yes, sure. >> >>>> Full: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4/ >> >> DeoptimizeObjectsALotThread is only used in compileBroker.cpp. >> You can move both declaration and definition to that file, no need to clobber >> thread.[c|h]pp. (and the static function deopt_objs_alot_thread_entry) >> >> Does JvmtiDeferredUpdates really need to be in thread.hpp, can't be in it's >> own >> hpp file? It doesn't seem right to add JVM TI classes into thread.hpp. >> >> Note that we also think we may have a bug in deopt: >> https://bugs.openjdk.java.net/browse/JDK-8238237 >> >> I think it would be best, if possible, to push after that is resolved. >> >> Not even nearly a full review :) >> >> Thanks, Robbin >> >> >>>> Incremental: >>>> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4.inc/ >>>> >>>> I was not able to eliminate the additional suspend flag now. I'll take care >> of this >>>> as soon as the >>>> existing suspend-resume-mechanism is reworked. >>>> >>>> Testing: >>>> >>>> Nightly tests @SAP: >>>> >>>> JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, >> Renaissance >>>> Suite, SAP specific tests >>>> with fastdebug and release builds on all platforms >>>> >>>> Stress testing with DeoptimizeObjectsALot running SPECjvm2008 40x >> parallel >>>> for 24h >>>> >>>> Thanks, Richard. >>>> >>>> >>>> More details on the changes: >>>> >>>> * Hide DeoptimizeObjectsALotThread from external view. >>>> >>>> * Changed EscapeBarrier_lock to be a _safepoint_check_never lock. >>>> It used to be _safepoint_check_sometimes, which will be eliminated >> sooner or >>>> later. >>>> I added explicit thread state changes with ThreadBlockInVM to code >> paths >>>> where we can wait() >>>> on EscapeBarrier_lock to become safepoint safe. >>>> >>>> * Use handshake EscapeBarrierSuspendHandshake to suspend target >> threads >>>> instead of vm operation >>>> VM_ThreadSuspendAllForObjDeopt. >>>> >>>> * Removed uses of Threads_lock. When adding a new thread we suspend >> it iff >>>> EA optimizations are >>>> being reverted. In the previous version we were waiting on >> Threads_lock >>>> while EA optimizations >>>> were reverted. See EscapeBarrier::thread_added(). >>>> >>>> * Made tests require Xmixed compilation mode. >>>> >>>> * Made tests agnostic regarding tiered compilation. >>>> I.e. tc isn't disabled anymore, and the tests can be run with tc enabled or >>>> disabled. >>>> >>>> * Exercising EATests.java as well with stress test options >>>> DeoptimizeObjectsALot* >>>> Due to the non-deterministic deoptimizations some tests need to be >> skipped. >>>> We do this to prevent bit-rot of the stress test code. >>>> >>>> * Executing EATests.java as well with graal if available. Driver for this is >>>> EATestsJVMCI.java. Graal cannot pass all tests, because it does not >> provide all >>>> the new debug info >>>> (namely not_global_escape_in_scope and arg_escape in >> scopeDesc.hpp). >>>> And graal does not yet support the JVMTI operations force early return >> and >>>> pop frame. >>>> >>>> * Removed tracing from new jdi tests in EATests.java. Too much trace >> output >>>> before the debugging >>>> connection is established can cause deadlock because output buffers fill >> up. >>>> (See https://bugs.openjdk.java.net/browse/JDK-8173304) >>>> >>>> * Many copyright year changes and smaller clean-up changes of testing >> code >>>> (trailing white-space and >>>> the like). >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Donnerstag, 19. Dezember 2019 03:12 >>>> To: Reingruber, Richard ; serviceability- >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; >> hotspot- >>>> runtime-dev at openjdk.java.net; Vladimir Kozlov >> (vladimir.kozlov at oracle.com) >>>> >>>> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better >> Performance in >>>> the Presence of JVMTI Agents >>>> >>>> Hi Richard, >>>> >>>> I think my issue is with the way EliminateNestedLocks works so I'm going >>>> to look into that more deeply. >>>> >>>> Thanks for the explanations. >>>> >>>> David >>>> >>>> On 18/12/2019 12:47 am, Reingruber, Richard wrote: >>>>> Hi David, >>>>> >>>>> > > > Some further queries/concerns: >>>>> > > > >>>>> > > > src/hotspot/share/runtime/objectMonitor.cpp >>>>> > > > >>>>> > > > Can you please explain the changes to ObjectMonitor::wait: >>>>> > > > >>>>> > > > ! _recursions = save // restore the old recursion count >>>>> > > > ! + jt->get_and_reset_relock_count_after_wait(); // >>>>> > > > increased by the deferred relock count >>>>> > > > >>>>> > > > what is the "deferred relock count"? I gather it relates to >>>>> > > > >>>>> > > > "The code was extended to be able to deoptimize objects of a >>>>> > > frame that >>>>> > > > is not the top frame and to let another thread than the owning >>>>> > > thread do >>>>> > > > it." >>>>> > > >>>>> > > Yes, these relate. Currently EA based optimizations are reverted, >> when a >>>> compiled frame is >>>>> > > replaced with corresponding interpreter frames. Part of this is >> relocking >>>> objects with eliminated >>>>> > > locking. New with the enhancement is that we do this also just >> before >>>> object references are >>>>> > > acquired through JVMTI. In this case we deoptimize also the >> owning >>>> compiled frame C and we >>>>> > > register deoptimized objects as deferred updates. When control >> returns >>>> to C it gets deoptimized, >>>>> > > we notice that objects are already deoptimized (reallocated and >>>> relocked), so we don't do it again >>>>> > > (relocking twice would be incorrect of course). Deferred updates >> are >>>> copied into the new >>>>> > > interpreter frames. >>>>> > > >>>>> > > Problem: relocking is not possible if the target thread T is waiting >> on the >>>> monitor that needs to >>>>> > > be relocked. This happens only with non-local objects with >>>> EliminateNestedLocks. Instead relocking >>>>> > > is deferred until T owns the monitor again. This is what the piece of >>>> code above does. >>>>> > >>>>> > Sorry I need some more detail here. How can you wait() on an >> object >>>>> > monitor if the object allocation and/or locking was optimised away? >> And >>>>> > what is a "non-local object" in this context? Isn't EA restricted to >>>>> > thread-confined objects? >>>>> >>>>> "Non-local object" is an object that escapes its thread. The issue I'm >>>> addressing with the changes >>>>> in ObjectMonitor::wait are almost unrelated to EA. They are caused by >>>> EliminateNestedLocks, where C2 >>>>> eliminates recursive locking of an already owned lock. The lock owning >> object >>>> exists on the heap, it >>>>> is locked and you can call wait() on it. >>>>> >>>>> EliminateLocks is the C2 option that controls lock elimination based on >> EA. >>>> Both optimizations have >>>>> in common that objects with eliminated locking need to be relocked >> when >>>> deoptimizing a frame, >>>>> i.e. when replacing a compiled frame with equivalent interpreter >>>>> frames. Deoptimization::relock_objects does that job for /all/ eliminated >>>> locks in scope. /All/ can >>>>> be a mix of eliminated nested locks and locks of not-escaping objects. >>>>> >>>>> New with the enhancement: I call relock_objects earlier, just before >> objects >>>> pontentially >>>>> escape. But then later when the owning compiled frame gets >> deoptimized, I >>>> must not do it again: >>>>> >>>>> See call to EscapeBarrier::objs_are_deoptimized in deoptimization.cpp: >>>>> >>>>> 373 if ((jvmci_enabled || ((DoEscapeAnalysis || >> EliminateNestedLocks) && >>>> EliminateLocks)) >>>>> 374 && !EscapeBarrier::objs_are_deoptimized(thread, >> deoptee.id())) { >>>>> 375 bool unused; >>>>> 376 eliminate_locks(thread, chunk, realloc_failures, deoptee, >> exec_mode, >>>> unused); >>>>> 377 } >>>>> >>>>> Now when calling relock_objects early it is quiet possible that I have to >> relock >>>> an object the >>>>> target thread currently waits for. Obviously I cannot relock in this case, >>>> instead I chose to >>>>> introduce relock_count_after_wait to JavaThread. >>>>> >>>>> > Is it just that some of the locking gets optimized away e.g. >>>>> > >>>>> > synchronised(obj) { >>>>> > synchronised(obj) { >>>>> > synchronised(obj) { >>>>> > obj.wait(); >>>>> > } >>>>> > } >>>>> > } >>>>> > >>>>> > If this is reduced to a form as-if it were a single lock of the monitor >>>>> > (due to EA) and the wait() triggers a JVM TI event which leads to the >>>>> > escape of "obj" then we need to reconstruct the true lock state, and >> so >>>>> > when the wait() internally unblocks and reacquires the monitor it >> has to >>>>> > set the true recursion count to 3, not the 1 that it appeared to be >> when >>>>> > wait() was initially called. Is that the scenario? >>>>> >>>>> Kind of... except that the locking is not eliminated due to EA and there is >> no >>>> JVM TI event >>>>> triggered by wait. >>>>> >>>>> Add >>>>> >>>>> LocalObject l1 = new LocalObject(); >>>>> >>>>> in front of the synchrnized blocks and assume a JVM TI agent acquires l1. >> This >>>> triggers the code in >>>>> question. >>>>> >>>>> See that relocking/reallocating is transactional. If it is done then for /all/ >>>> objects in scope and it is >>>>> done at most once. It wouldn't be quite so easy to split this in relocking >> of >>>> nested/EA-based >>>>> eliminated locks. >>>>> >>>>> > If so I find this truly awful. Anyone using wait() in a realistic form >>>>> > requires a notification and so the object cannot be thread confined. >> In >>>>> >>>>> It is not thread confined. >>>>> >>>>> > which case I would strongly argue that upon hitting the wait() the >> deopt >>>>> > should occur unconditionally and so the lock state is correct before >> we >>>>> > wait and so we don't need to mess with the recursion count >> internally >>>>> > when we reacquire the monitor. >>>>> > >>>>> > > >>>>> > > > which I don't like the sound of at all when it comes to >> ObjectMonitor >>>>> > > > state. So I'd like to understand in detail exactly what is going on >> here >>>>> > > > and why. This is a very intrusive change that seems to badly >> break >>>>> > > > encapsulation and impacts future changes to ObjectMonitor >> that are >>>> under >>>>> > > > investigation. >>>>> > > >>>>> > > I would not regard this as breaking encapsulation. Certainly not >> badly. >>>>> > > >>>>> > > I've added a property relock_count_after_wait to JavaThread. The >>>> property is well >>>>> > > encapsulated. Future ObjectMonitor implementations have to deal >> with >>>> recursion too. They are free >>>>> > > in choosing a way to do that as long as that property is taken into >>>> account. This is hardly a >>>>> > > limitation. >>>>> > >>>>> > I do think this badly breaks encapsulation as you have to add a >> callout >>>>> > from the guts of the ObjectMonitor code to reach into the thread to >> get >>>>> > this lock count adjustment. I understand why you have had to do >> this but >>>>> > I would much rather see a change to the EA optimisation strategy so >> that >>>>> > this is not needed. >>>>> > >>>>> > > Note also that the property is a straight forward extension of the >>>> existing concept of deferred >>>>> > > local updates. It is embedded into the structure holding them. So >> not >>>> even the footprint of a >>>>> > > JavaThread is enlarged if no deferred updates are generated. >>>>> > >>>>> > [...] >>>>> > >>>>> > > >>>>> > > I'm actually duplicating the existing external suspend mechanism, >>>> because a thread can be >>>>> > > suspended at most once. And hey, and don't like that either! But it >>>> seems not unlikely that the >>>>> > > duplicate can be removed together with the original and the new >> type >>>> of handshakes that will be >>>>> > > used for thread suspend can be used for object deoptimization >> too. See >>>> today's discussion in >>>>> > > JDK-8227745 [2]. >>>>> > >>>>> > I hope that discussion bears some fruit, at the moment it seems not >> to >>>>> > be possible to use handshakes here. :( >>>>> > >>>>> > The external suspend mechanism is a royal pain in the proverbial >> that we >>>>> > have to carefully live with. The idea that we're duplicating that for >>>>> > use in another fringe area of functionality does not thrill me at all. >>>>> > >>>>> > To be clear, I understand the problem that exists and that you wish >> to >>>>> > solve, but for the runtime parts I balk at the complexity cost of >>>>> > solving it. >>>>> >>>>> I know it's complex, but by far no rocket science. >>>>> >>>>> Also I find it hard to imagine another fix for JDK-8233915 besides >> changing >>>> the JVM TI specification. >>>>> >>>>> Thanks, Richard. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes >>>>> Sent: Dienstag, 17. Dezember 2019 08:03 >>>>> To: Reingruber, Richard ; serviceability- >>>> dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; >> hotspot- >>>> runtime-dev at openjdk.java.net; Vladimir Kozlov >> (vladimir.kozlov at oracle.com) >>>> >>>>> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better >> Performance >>>> in the Presence of JVMTI Agents >>>>> >>>>> >>>>> >>>>> David >>>>> >>>>> On 17/12/2019 4:57 pm, David Holmes wrote: >>>>>> Hi Richard, >>>>>> >>>>>> On 14/12/2019 5:01 am, Reingruber, Richard wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> ?? > Some further queries/concerns: >>>>>>> ?? > >>>>>>> ?? > src/hotspot/share/runtime/objectMonitor.cpp >>>>>>> ?? > >>>>>>> ?? > Can you please explain the changes to ObjectMonitor::wait: >>>>>>> ?? > >>>>>>> ?? > !?? _recursions = save????? // restore the old recursion count >>>>>>> ?? > !???????????????? + jt->get_and_reset_relock_count_after_wait(); // >>>>>>> ?? > increased by the deferred relock count >>>>>>> ?? > >>>>>>> ?? > what is the "deferred relock count"? I gather it relates to >>>>>>> ?? > >>>>>>> ?? > "The code was extended to be able to deoptimize objects of a >>>>>>> frame that >>>>>>> ?? > is not the top frame and to let another thread than the owning >>>>>>> thread do >>>>>>> ?? > it." >>>>>>> >>>>>>> Yes, these relate. Currently EA based optimizations are reverted, >> when >>>>>>> a compiled frame is replaced >>>>>>> with corresponding interpreter frames. Part of this is relocking >>>>>>> objects with eliminated >>>>>>> locking. New with the enhancement is that we do this also just before >>>>>>> object references are acquired >>>>>>> through JVMTI. In this case we deoptimize also the owning compiled >>>>>>> frame C and we register >>>>>>> deoptimized objects as deferred updates. When control returns to C >> it >>>>>>> gets deoptimized, we notice >>>>>>> that objects are already deoptimized (reallocated and relocked), so >> we >>>>>>> don't do it again (relocking >>>>>>> twice would be incorrect of course). Deferred updates are copied into >>>>>>> the new interpreter frames. >>>>>>> >>>>>>> Problem: relocking is not possible if the target thread T is waiting >>>>>>> on the monitor that needs to be >>>>>>> relocked. This happens only with non-local objects with >>>>>>> EliminateNestedLocks. Instead relocking is >>>>>>> deferred until T owns the monitor again. This is what the piece of >>>>>>> code above does. >>>>>> >>>>>> Sorry I need some more detail here. How can you wait() on an object >>>>>> monitor if the object allocation and/or locking was optimised away? >> And >>>>>> what is a "non-local object" in this context? Isn't EA restricted to >>>>>> thread-confined objects? >>>>>> >>>>>> Is it just that some of the locking gets optimized away e.g. >>>>>> >>>>>> synchronised(obj) { >>>>>> ? synchronised(obj) { >>>>>> ??? synchronised(obj) { >>>>>> ????? obj.wait(); >>>>>> ??? } >>>>>> ? } >>>>>> } >>>>>> >>>>>> If this is reduced to a form as-if it were a single lock of the monitor >>>>>> (due to EA) and the wait() triggers a JVM TI event which leads to the >>>>>> escape of "obj" then we need to reconstruct the true lock state, and so >>>>>> when the wait() internally unblocks and reacquires the monitor it has to >>>>>> set the true recursion count to 3, not the 1 that it appeared to be when >>>>>> wait() was initially called. Is that the scenario? >>>>>> >>>>>> If so I find this truly awful. Anyone using wait() in a realistic form >>>>>> requires a notification and so the object cannot be thread confined. In >>>>>> which case I would strongly argue that upon hitting the wait() the >> deopt >>>>>> should occur unconditionally and so the lock state is correct before we >>>>>> wait and so we don't need to mess with the recursion count internally >>>>>> when we reacquire the monitor. >>>>>> >>>>>>> >>>>>>> ?? > which I don't like the sound of at all when it comes to >>>>>>> ObjectMonitor >>>>>>> ?? > state. So I'd like to understand in detail exactly what is going >>>>>>> on here >>>>>>> ?? > and why.? This is a very intrusive change that seems to badly >> break >>>>>>> ?? > encapsulation and impacts future changes to ObjectMonitor that >>>>>>> are under >>>>>>> ?? > investigation. >>>>>>> >>>>>>> I would not regard this as breaking encapsulation. Certainly not badly. >>>>>>> >>>>>>> I've added a property relock_count_after_wait to JavaThread. The >>>>>>> property is well >>>>>>> encapsulated. Future ObjectMonitor implementations have to deal >> with >>>>>>> recursion too. They are free in >>>>>>> choosing a way to do that as long as that property is taken into >>>>>>> account. This is hardly a >>>>>>> limitation. >>>>>> >>>>>> I do think this badly breaks encapsulation as you have to add a callout >>>>>> from the guts of the ObjectMonitor code to reach into the thread to >> get >>>>>> this lock count adjustment. I understand why you have had to do this >> but >>>>>> I would much rather see a change to the EA optimisation strategy so >> that >>>>>> this is not needed. >>>>>> >>>>>>> Note also that the property is a straight forward extension of the >>>>>>> existing concept of deferred >>>>>>> local updates. It is embedded into the structure holding them. So not >>>>>>> even the footprint of a >>>>>>> JavaThread is enlarged if no deferred updates are generated. >>>>>>> >>>>>>> ?? > --- >>>>>>> ?? > >>>>>>> ?? > src/hotspot/share/runtime/thread.cpp >>>>>>> ?? > >>>>>>> ?? > Can you please explain why >>>>>>> JavaThread::wait_for_object_deoptimization >>>>>>> ?? > has to be handcrafted in this way rather than using proper >>>>>>> transitions. >>>>>>> ?? > >>>>>>> >>>>>>> I wrote wait_for_object_deoptimization taking >>>>>>> JavaThread::java_suspend_self_with_safepoint_check >>>>>>> as template. So in short: for the same reasons :) >>>>>>> >>>>>>> Threads reach both methods as part of thread state transitions, >>>>>>> therefore special handling is >>>>>>> required to change thread state on top of ongoing transitions. >>>>>>> >>>>>>> ?? > We got rid of "deopt suspend" some time ago and it is disturbing >>>>>>> to see >>>>>>> ?? > it being added back (effectively). This seems like it may be >>>>>>> something >>>>>>> ?? > that handshakes could be used for. >>>>>>> >>>>>>> Deopt suspend used to be something rather different with a similar >>>>>>> name[1]. It is not being added back. >>>>>> >>>>>> I stand corrected. Despite comments in the code to the contrary >>>>>> deopt_suspend didn't actually cause a self-suspend. I was doing a lot of >>>>>> cleanup in this area 13 years ago :) >>>>>> >>>>>>> >>>>>>> I'm actually duplicating the existing external suspend mechanism, >>>>>>> because a thread can be suspended >>>>>>> at most once. And hey, and don't like that either! But it seems not >>>>>>> unlikely that the duplicate can >>>>>>> be removed together with the original and the new type of >> handshakes >>>>>>> that will be used for >>>>>>> thread suspend can be used for object deoptimization too. See >> today's >>>>>>> discussion in JDK-8227745 [2]. >>>>>> >>>>>> I hope that discussion bears some fruit, at the moment it seems not to >>>>>> be possible to use handshakes here. :( >>>>>> >>>>>> The external suspend mechanism is a royal pain in the proverbial that >> we >>>>>> have to carefully live with. The idea that we're duplicating that for >>>>>> use in another fringe area of functionality does not thrill me at all. >>>>>> >>>>>> To be clear, I understand the problem that exists and that you wish to >>>>>> solve, but for the runtime parts I balk at the complexity cost of >>>>>> solving it. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Thanks, Richard. >>>>>>> >>>>>>> [1] Deopt suspend was something like an async. handshake for >>>>>>> architectures with register windows, >>>>>>> ???? where patching the return pc for deoptimization of a compiled >>>>>>> frame was racy if the owner thread >>>>>>> ???? was in native code. Instead a "deopt" suspend flag was set on >>>>>>> which the thread patched its own >>>>>>> ???? frame upon return from native. So no thread was suspended. It >> got >>>>>>> its name only from the name of >>>>>>> ???? the flags. >>>>>>> >>>>>>> [2] Discussion about using handshakes to sync. with the target thread: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK- >>>> >> 8227745?focusedCommentId=14306727&page=com.atlassian.jira.plugin.syst >> e >>>> m.issuetabpanels:comment-tabpanel#comment-14306727 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes >>>>>>> Sent: Freitag, 13. Dezember 2019 00:56 >>>>>>> To: Reingruber, Richard ; >>>>>>> serviceability-dev at openjdk.java.net; >>>>>>> hotspot-compiler-dev at openjdk.java.net; >>>>>>> hotspot-runtime-dev at openjdk.java.net >>>>>>> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better >>>>>>> Performance in the Presence of JVMTI Agents >>>>>>> >>>>>>> Hi Richard, >>>>>>> >>>>>>> Some further queries/concerns: >>>>>>> >>>>>>> src/hotspot/share/runtime/objectMonitor.cpp >>>>>>> >>>>>>> Can you please explain the changes to ObjectMonitor::wait: >>>>>>> >>>>>>> !?? _recursions = save????? // restore the old recursion count >>>>>>> !???????????????? + jt->get_and_reset_relock_count_after_wait(); // >>>>>>> increased by the deferred relock count >>>>>>> >>>>>>> what is the "deferred relock count"? I gather it relates to >>>>>>> >>>>>>> "The code was extended to be able to deoptimize objects of a frame >> that >>>>>>> is not the top frame and to let another thread than the owning thread >> do >>>>>>> it." >>>>>>> >>>>>>> which I don't like the sound of at all when it comes to ObjectMonitor >>>>>>> state. So I'd like to understand in detail exactly what is going on here >>>>>>> and why.? This is a very intrusive change that seems to badly break >>>>>>> encapsulation and impacts future changes to ObjectMonitor that are >> under >>>>>>> investigation. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/hotspot/share/runtime/thread.cpp >>>>>>> >>>>>>> Can you please explain why >> JavaThread::wait_for_object_deoptimization >>>>>>> has to be handcrafted in this way rather than using proper transitions. >>>>>>> >>>>>>> We got rid of "deopt suspend" some time ago and it is disturbing to >> see >>>>>>> it being added back (effectively). This seems like it may be something >>>>>>> that handshakes could be used for. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 12/12/2019 7:02 am, David Holmes wrote: >>>>>>>> On 12/12/2019 1:07 am, Reingruber, Richard wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> ??? > Most of the details here are in areas I can comment on in >> detail, >>>>>>>>> but I >>>>>>>>> ??? > did take an initial general look at things. >>>>>>>>> >>>>>>>>> Thanks for taking the time! >>>>>>>> >>>>>>>> Apologies the above should read: >>>>>>>> >>>>>>>> "Most of the details here are in areas I *can't* comment on in detail >>>>>>>> ..." >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> ??? > The only thing that jumped out at me is that I think the >>>>>>>>> ??? > DeoptimizeObjectsALotThread should be a hidden thread. >>>>>>>>> ??? > >>>>>>>>> ??? > +? bool is_hidden_from_external_view() const { return true; } >>>>>>>>> >>>>>>>>> Yes, it should. Will add the method like above. >>>>>>>>> >>>>>>>>> ??? > Also I don't see any testing of the >> DeoptimizeObjectsALotThread. >>>>>>>>> Without >>>>>>>>> ??? > active testing this will just bit-rot. >>>>>>>>> >>>>>>>>> DeoptimizeObjectsALot is meant for stress testing with a larger >>>>>>>>> workload. I will add a minimal test >>>>>>>>> to keep it fresh. >>>>>>>>> >>>>>>>>> ??? > Also on the tests I don't understand your @requires clause: >>>>>>>>> ??? > >>>>>>>>> ??? >?? @requires ((vm.compMode != "Xcomp") & >> vm.compiler2.enabled >>>> & >>>>>>>>> ??? > (vm.opt.TieredCompilation != true)) >>>>>>>>> ??? > >>>>>>>>> ??? > This seems to require that TieredCompilation is disabled, but >>>>>>>>> tiered is >>>>>>>>> ??? > our normal mode of operation. ?? >>>>>>>>> ??? > >>>>>>>>> >>>>>>>>> I removed the clause. I guess I wanted to target the tests towards >> the >>>>>>>>> code they are supposed to >>>>>>>>> test, and it's easier to analyze failures w/o tiered compilation and >>>>>>>>> with just one compiler thread. >>>>>>>>> >>>>>>>>> Additionally I will make use of >>>>>>>>> compiler.whitebox.CompilerWhiteBoxTest.THRESHOLD in the tests. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Richard. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes >>>>>>>>> Sent: Mittwoch, 11. Dezember 2019 08:03 >>>>>>>>> To: Reingruber, Richard ; >>>>>>>>> serviceability-dev at openjdk.java.net; >>>>>>>>> hotspot-compiler-dev at openjdk.java.net; >>>>>>>>> hotspot-runtime-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better >>>>>>>>> Performance in the Presence of JVMTI Agents >>>>>>>>> >>>>>>>>> Hi Richard, >>>>>>>>> >>>>>>>>> On 11/12/2019 7:45 am, Reingruber, Richard wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I would like to get reviews please for >>>>>>>>>> >>>>>>>>>> >> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/ >>>>>>>>>> >>>>>>>>>> Corresponding RFE: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8227745 >>>>>>>>>> >>>>>>>>>> Fixes also https://bugs.openjdk.java.net/browse/JDK-8233915 >>>>>>>>>> And potentially https://bugs.openjdk.java.net/browse/JDK- >> 8214584 [1] >>>>>>>>>> >>>>>>>>>> Vladimir Kozlov kindly put webrev.3 through tier1-8 testing >> without >>>>>>>>>> issues (thanks!). In addition the >>>>>>>>>> change is being tested at SAP since I posted the first RFR some >>>>>>>>>> months ago. >>>>>>>>>> >>>>>>>>>> The intention of this enhancement is to benefit performance wise >> from >>>>>>>>>> escape analysis even if JVMTI >>>>>>>>>> agents request capabilities that allow them to access local variable >>>>>>>>>> values. E.g. if you start-up >>>>>>>>>> with -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, >> then >>>>>>>>>> escape analysis is disabled right >>>>>>>>>> from the beginning, well before a debugger attaches -- if ever one >>>>>>>>>> should do so. With the >>>>>>>>>> enhancement, escape analysis will remain enabled until and after >> a >>>>>>>>>> debugger attaches. EA based >>>>>>>>>> optimizations are reverted just before an agent acquires the >>>>>>>>>> reference to an object. In the JBS item >>>>>>>>>> you'll find more details. >>>>>>>>> >>>>>>>>> Most of the details here are in areas I can comment on in detail, but >> I >>>>>>>>> did take an initial general look at things. >>>>>>>>> >>>>>>>>> The only thing that jumped out at me is that I think the >>>>>>>>> DeoptimizeObjectsALotThread should be a hidden thread. >>>>>>>>> >>>>>>>>> +? bool is_hidden_from_external_view() const { return true; } >>>>>>>>> >>>>>>>>> Also I don't see any testing of the DeoptimizeObjectsALotThread. >>>>>>>>> Without >>>>>>>>> active testing this will just bit-rot. >>>>>>>>> >>>>>>>>> Also on the tests I don't understand your @requires clause: >>>>>>>>> >>>>>>>>> ??? @requires ((vm.compMode != "Xcomp") & >> vm.compiler2.enabled & >>>>>>>>> (vm.opt.TieredCompilation != true)) >>>>>>>>> >>>>>>>>> This seems to require that TieredCompilation is disabled, but tiered >> is >>>>>>>>> our normal mode of operation. ?? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Richard. >>>>>>>>>> >>>>>>>>>> [1] Experimental fix for JDK-8214584 based on JDK-8227745 >>>>>>>>>> >>>> >> http://cr.openjdk.java.net/~rrich/webrevs/2019/8214584/experiment_v1.pa >> tc >>>> h >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From david.holmes at oracle.com Wed Apr 1 10:05:32 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Apr 2020 20:05:32 +1000 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <8ced0d82-4125-7179-bac2-c8ce54807274@oracle.com> Message-ID: <936c63af-cbd0-234a-94e5-5bc03f237b3c@oracle.com> On 1/04/2020 11:02 am, Yasumasa Suenaga wrote: > Thanks Dan and Serguei! > > I added a comment for this to JDK-8201641. > > David, can you share Bug ID for thread-to-thread handshake? > I want to record it to JDK-8201641 as a blocker. https://bugs.openjdk.java.net/browse/JDK-8240918 I heard the RFR could be as soon as tomorrow :) Cheers, David > > Yasumasa > > > On 2020/04/01 1:59, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> Yes, this works needs to be done. >> I'll take look at you webrev. >> >> Thanks, >> Serguei >> >> On 3/31/20 07:41, Daniel D. Daugherty wrote: >>> Add Robbin to this thread... >>> >>> >>> This reminded of the following RFE that Robbin filed: >>> >>> ??? JDK-8201641 JVMTI: GetThreadListStackTraces should use >>> Thread-Local Handshakes >>> ??? https://bugs.openjdk.java.net/browse/JDK-8201641 >>> >>> We could update 8201641 to include everything that Yasumasa-san is >>> requesting. >>> Would be a good place to track it... >>> >>> Dan >>> >>> >>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> On 2020/03/31 19:16, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Many JVMTI functions uses VM Operation to get information. However >>>>>> some of them need to stop only one thread - they don't need to >>>>>> stop all threads. >>>>>> So I think we can use Thread Local Handshake as this webrev. It is >>>>>> example for GetOneCurrentContendedMonitor(). >>>>> >>>>> True, but at the moment handshakes involve the VMThread. There is >>>>> work being done to support direct thread-to-thread handshakes and >>>>> once that is done this kind of conversion should be more easily >>>>> done. It might be worth waiting for that. >>>> >>>> Thanks, I will be back to this topic when thread-to-thread handshake >>>> is done. >>>> I wondered at first why VMThread involves handshake. Its improvement >>>> is welcome for me ;) >>>> >>>> >>>> Cheers, >>>> >>>> Yasumasa >>>> >>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>> >>>>> An observation, it seems to me that calling_thread is not used when >>>>> this is not a VMOperation. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Also I think we can replace following VM Operations to Thread >>>>>> Local Handshake: >>>>>> >>>>>> class VM_GetCurrentLocation >>>>>> class VM_EnterInterpOnlyMode >>>>>> class VM_UpdateForPopTopFrame >>>>>> class VM_SetFramePop >>>>>> class VM_GetOwnedMonitorInfo >>>>>> class VM_GetCurrentContendedMonitor >>>>>> class VM_GetFrameCount >>>>>> class VM_GetFrameLocation >>>>>> >>>>>> What do you think? >>>>>> It it is acceptable, I will file it to JBS and send review request. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>> >> From kevin.walls at oracle.com Wed Apr 1 10:22:37 2020 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 1 Apr 2020 11:22:37 +0100 Subject: Discussion about fixing deprecation in jdk.hotspot.agent In-Reply-To: <1cc556ce-67ed-1e6f-ee53-36d8227d0e1e@oracle.com> References: <1916207b-de97-1f25-f93c-8830025fad62@oracle.com> <113dd83a-82a3-88fc-8f31-fe9bfd00c12c@oracle.com> <12e28226-136b-3391-ca01-e9e04058a2a8@oracle.com> <71739959-0aaf-c973-10d2-36f4295ddc37@oracle.com> <1cc556ce-67ed-1e6f-ee53-36d8227d0e1e@oracle.com> Message-ID: <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> Hi Coleen and all - Given the choice I'd ask that we don't remove attach/detach because it limits the scope of what a clhsdb can do in future. Commands like jstack are a one-shot operation.? A Tool like clhsdb is ideally more flexible than that. The SA is (I suggest) "too static" in its "there is one VM" approach, so we can't write a Tool that attaches to multiple VMs. If we remove attach/detach, it could not even gather information in a series of requests.? This is not going to be in the product any time soon, and maybe never, but it doesn't look right that we cut off such experiments. Removing the Observer, yes would imply making detach into detach and exit.? I think the clhsdb "attach" command would still work (once only!) but is odd without detach (so do we make "bin/jhsdb clhsdb" require parameters...). It looks like this changes the direction of the Tools in order to remove the deprecation warnings. Magnus' webrev http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01/ does add/duplicate some code, but I like it for keeping things working 8-) Thanks Kevin On 31/03/2020 22:20, coleen.phillimore at oracle.com wrote: > > > On 3/31/20 4:55 PM, Chris Plummer wrote: >> On 3/31/20 1:32 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 3/31/20 12:19 PM, Poonam Parhar wrote: >>>> Hello Coleen, >>>> >>>> Does the removal of this code only impact the 'reattach' >>>> functionality, and it does not affect any commands available in >>>> 'clhsdb' once it is attached to a core file? If that's true, then I >>>> think it should be okay to remove this code. >>> >>> Hi Poonam,? Thank you for answering. Yes, this patch only removes >>> the reattach functionality.? I tried out the other clhsdb commands >>> from your wiki page, and they worked fine, including object and heap >>> inspection. >> I'm trying to understand exactly when all these static initializes >> are triggered. Is it only after you do an attach? >> >> The implementation of clhsdb reattach is exactly the same as doing a >> detach followed by an attach to the same process. I'm not sure how >> much value it has, but I think in general the removal of this code >> means you can't detach and then attach to anything, even a different >> pid. So "detach" might as well become "detach-and-exit", because your >> clhsdb session is dead once you detach. Do we really want to do this? > > Well, that was my question. It seems like you could just exit and > start up jhsdb again and that's more like something someone would do > just as easily.? Given the use cases that we've seen from sustaining, > this appears to be unneeded functionality. > > The original mail was proposing adding more code to work around the > deprecation messages.? It seems like more code should not be added for > something that is unused. > > thanks, > Coleen > >> >> Chris >>> >>> Thanks, >>> Coleen >>>> >>>> Thanks, >>>> Poonam >>>> >>>> On 3/31/20 5:34 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> To answer my own question, this functionality is used to allow >>>>> detach/reattach from {cl}hsdb.? Which seems to work on linux but >>>>> not windows with this code removed. >>>>> >>>>> The next question is whether this is useful functionality to >>>>> justify all this code (900+ and this new code that Magnus has >>>>> added).? Can't you just exit and restart the clhsdb process on the >>>>> core file or process? >>>>> >>>>> For the record, this is me playing with python to remove this code. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2020/01/webrev/index.html >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 3/30/20 3:04 PM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> I was wondering why this is needed when debugging a core file, >>>>>> which is the key thing we need the SA for: >>>>>> >>>>>> ? /** This is used by both the debugger and any runtime system. >>>>>> It is >>>>>> ????? the basic mechanism by which classes which mimic underlying VM >>>>>> ????? functionality cause themselves to be initialized. The given >>>>>> ????? observer will be notified (with arguments (null, null)) >>>>>> when the >>>>>> ????? VM is re-initialized, as well as when it registers itself with >>>>>> ????? the VM. */ >>>>>> ? public static void registerVMInitializedObserver(Observer o) { >>>>>> ??? vmInitializedObservers.add(o); >>>>>> ??? o.update(null, null); >>>>>> ? } >>>>>> >>>>>> It seems like if it isn't needed, we shouldn't add these classes >>>>>> and remove their use. >>>>>> >>>>>> Coleen >>>>>> >>>>>> On 3/30/20 8:14 AM, Magnus Ihse Bursie wrote: >>>>>>> No opinions on this? >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> On 2020-03-25 23:34, Magnus Ihse Bursie wrote: >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> As a follow-up to the ongoing review for JDK-8241618, I have >>>>>>>> also looked at fixing the deprecation warnings in >>>>>>>> jdk.hotspot.agent. These fall in three broad categories: >>>>>>>> >>>>>>>> * Deprecation of the boxing type constructors (e.g. "new >>>>>>>> Integer(42)"). >>>>>>>> >>>>>>>> * Deprecation of java.util.Observer and Observable. >>>>>>>> >>>>>>>> * The rest (mostly Class.newInstance(), and a few number of >>>>>>>> other odd deprecations) >>>>>>>> >>>>>>>> The first category is trivial to fix. The last category need >>>>>>>> some special discussion. But the overwhelming majority of >>>>>>>> deprecation warnings come from the use of Observer and >>>>>>>> Observable. This really dwarfs anything else, and needs to be >>>>>>>> handled first, otherwise it's hard to even spot the other issues. >>>>>>>> >>>>>>>> My analysis of the situation is that the deprecation of >>>>>>>> Observer and Observable seems a bit harsh, from the PoV of >>>>>>>> jdk.hotspot.agent. Sure, it might be limited, but I think it >>>>>>>> does exactly what is needed here. So the migration suggested in >>>>>>>> Observable (java.beans or java.util.concurrent) seems overkill. >>>>>>>> If there are genuine threading issues at play here, this >>>>>>>> assumption might be wrong, and then maybe going the j.u.c. >>>>>>>> route is correct. >>>>>>>> >>>>>>>> But if that's not, the main goal should be to stay with the >>>>>>>> current implementation. One way to do this is to sprinkle the >>>>>>>> code with @SuppressWarning. But I think a better way would be >>>>>>>> to just implement our own Observer and Observable. After all, >>>>>>>> the classes are trivial. >>>>>>>> >>>>>>>> I've made a mock-up of this solution, were I just copied the >>>>>>>> java.util.Observer and Observable, and removed the deprecation >>>>>>>> annotations. The only thing needed for the rest of the code is >>>>>>>> to make sure we import these; I've done this for three >>>>>>>> arbitrarily selected classes just to show what the change would >>>>>>>> typically look like. Here's the mock-up: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01 >>>>>>>> >>>>>>>> Let me know what you think. >>>>>>>> >>>>>>>> /Magnus >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > From magnus.ihse.bursie at oracle.com Wed Apr 1 12:13:59 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 1 Apr 2020 14:13:59 +0200 Subject: Discussion about fixing deprecation in jdk.hotspot.agent In-Reply-To: <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> References: <1916207b-de97-1f25-f93c-8830025fad62@oracle.com> <113dd83a-82a3-88fc-8f31-fe9bfd00c12c@oracle.com> <12e28226-136b-3391-ca01-e9e04058a2a8@oracle.com> <71739959-0aaf-c973-10d2-36f4295ddc37@oracle.com> <1cc556ce-67ed-1e6f-ee53-36d8227d0e1e@oracle.com> <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> Message-ID: <1b03ec6c-aa7a-859b-1bdf-f061a948e6f0@oracle.com> On 2020-04-01 12:22, Kevin Walls wrote: > Hi Coleen and all - > > Given the choice I'd ask that we don't remove attach/detach because it > limits the scope of what a clhsdb can do in future. Commands like > jstack are a one-shot operation.? A Tool like clhsdb is ideally more > flexible than that. > > The SA is (I suggest) "too static" in its "there is one VM" approach, > so we can't write a Tool that attaches to multiple VMs. If we remove > attach/detach, it could not even gather information in a series of > requests.? This is not going to be in the product any time soon, and > maybe never, but it doesn't look right that we cut off such experiments. > > Removing the Observer, yes would imply making detach into detach and > exit.? I think the clhsdb "attach" command would still work (once > only!) but is odd without detach (so do we make "bin/jhsdb clhsdb" > require parameters...). > > It looks like this changes the direction of the Tools in order to > remove the deprecation warnings. > > Magnus' webrev > http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01/ > does add/duplicate some code, but I like it for keeping things working 8-) Here's an updated version of that approach that minimizes the amount of new code: http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.03 The difference is that I do not duplicate the classes themselves, I just subclass them to get a single point where the @SuppressWarnings can be put. The only change needed in the rest of the files is to make sure we import these classes instead of the ones in java.util. /Magnus > > > Thanks > Kevin > > > On 31/03/2020 22:20, coleen.phillimore at oracle.com wrote: >> >> >> On 3/31/20 4:55 PM, Chris Plummer wrote: >>> On 3/31/20 1:32 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 3/31/20 12:19 PM, Poonam Parhar wrote: >>>>> Hello Coleen, >>>>> >>>>> Does the removal of this code only impact the 'reattach' >>>>> functionality, and it does not affect any commands available in >>>>> 'clhsdb' once it is attached to a core file? If that's true, then >>>>> I think it should be okay to remove this code. >>>> >>>> Hi Poonam,? Thank you for answering. Yes, this patch only removes >>>> the reattach functionality.? I tried out the other clhsdb commands >>>> from your wiki page, and they worked fine, including object and >>>> heap inspection. >>> I'm trying to understand exactly when all these static initializes >>> are triggered. Is it only after you do an attach? >>> >>> The implementation of clhsdb reattach is exactly the same as doing a >>> detach followed by an attach to the same process. I'm not sure how >>> much value it has, but I think in general the removal of this code >>> means you can't detach and then attach to anything, even a different >>> pid. So "detach" might as well become "detach-and-exit", because >>> your clhsdb session is dead once you detach. Do we really want to do >>> this? >> >> Well, that was my question. It seems like you could just exit and >> start up jhsdb again and that's more like something someone would do >> just as easily.? Given the use cases that we've seen from sustaining, >> this appears to be unneeded functionality. >> >> The original mail was proposing adding more code to work around the >> deprecation messages.? It seems like more code should not be added >> for something that is unused. >> >> thanks, >> Coleen >> >>> >>> Chris >>>> >>>> Thanks, >>>> Coleen >>>>> >>>>> Thanks, >>>>> Poonam >>>>> >>>>> On 3/31/20 5:34 AM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> To answer my own question, this functionality is used to allow >>>>>> detach/reattach from {cl}hsdb.? Which seems to work on linux but >>>>>> not windows with this code removed. >>>>>> >>>>>> The next question is whether this is useful functionality to >>>>>> justify all this code (900+ and this new code that Magnus has >>>>>> added).? Can't you just exit and restart the clhsdb process on >>>>>> the core file or process? >>>>>> >>>>>> For the record, this is me playing with python to remove this code. >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2020/01/webrev/index.html >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 3/30/20 3:04 PM, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> I was wondering why this is needed when debugging a core file, >>>>>>> which is the key thing we need the SA for: >>>>>>> >>>>>>> ? /** This is used by both the debugger and any runtime system. >>>>>>> It is >>>>>>> ????? the basic mechanism by which classes which mimic >>>>>>> underlying VM >>>>>>> ????? functionality cause themselves to be initialized. The given >>>>>>> ????? observer will be notified (with arguments (null, null)) >>>>>>> when the >>>>>>> ????? VM is re-initialized, as well as when it registers itself >>>>>>> with >>>>>>> ????? the VM. */ >>>>>>> ? public static void registerVMInitializedObserver(Observer o) { >>>>>>> ??? vmInitializedObservers.add(o); >>>>>>> ??? o.update(null, null); >>>>>>> ? } >>>>>>> >>>>>>> It seems like if it isn't needed, we shouldn't add these classes >>>>>>> and remove their use. >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> On 3/30/20 8:14 AM, Magnus Ihse Bursie wrote: >>>>>>>> No opinions on this? >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>> On 2020-03-25 23:34, Magnus Ihse Bursie wrote: >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> As a follow-up to the ongoing review for JDK-8241618, I have >>>>>>>>> also looked at fixing the deprecation warnings in >>>>>>>>> jdk.hotspot.agent. These fall in three broad categories: >>>>>>>>> >>>>>>>>> * Deprecation of the boxing type constructors (e.g. "new >>>>>>>>> Integer(42)"). >>>>>>>>> >>>>>>>>> * Deprecation of java.util.Observer and Observable. >>>>>>>>> >>>>>>>>> * The rest (mostly Class.newInstance(), and a few number of >>>>>>>>> other odd deprecations) >>>>>>>>> >>>>>>>>> The first category is trivial to fix. The last category need >>>>>>>>> some special discussion. But the overwhelming majority of >>>>>>>>> deprecation warnings come from the use of Observer and >>>>>>>>> Observable. This really dwarfs anything else, and needs to be >>>>>>>>> handled first, otherwise it's hard to even spot the other issues. >>>>>>>>> >>>>>>>>> My analysis of the situation is that the deprecation of >>>>>>>>> Observer and Observable seems a bit harsh, from the PoV of >>>>>>>>> jdk.hotspot.agent. Sure, it might be limited, but I think it >>>>>>>>> does exactly what is needed here. So the migration suggested >>>>>>>>> in Observable (java.beans or java.util.concurrent) seems >>>>>>>>> overkill. If there are genuine threading issues at play here, >>>>>>>>> this assumption might be wrong, and then maybe going the >>>>>>>>> j.u.c. route is correct. >>>>>>>>> >>>>>>>>> But if that's not, the main goal should be to stay with the >>>>>>>>> current implementation. One way to do this is to sprinkle the >>>>>>>>> code with @SuppressWarning. But I think a better way would be >>>>>>>>> to just implement our own Observer and Observable. After all, >>>>>>>>> the classes are trivial. >>>>>>>>> >>>>>>>>> I've made a mock-up of this solution, were I just copied the >>>>>>>>> java.util.Observer and Observable, and removed the deprecation >>>>>>>>> annotations. The only thing needed for the rest of the code is >>>>>>>>> to make sure we import these; I've done this for three >>>>>>>>> arbitrarily selected classes just to show what the change >>>>>>>>> would typically look like. Here's the mock-up: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01 >>>>>>>>> >>>>>>>>> Let me know what you think. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> From suenaga at oss.nttdata.com Wed Apr 1 12:29:39 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 1 Apr 2020 21:29:39 +0900 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: <936c63af-cbd0-234a-94e5-5bc03f237b3c@oracle.com> References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <8ced0d82-4125-7179-bac2-c8ce54807274@oracle.com> <936c63af-cbd0-234a-94e5-5bc03f237b3c@oracle.com> Message-ID: <1bd2bd6f-d51d-d02f-e2df-a4796c2a2d72@oss.nttdata.com> Thanks David! If JDK-8201641 is not assigned when JDK-8240918 is resolved, I will start to work for JDK-8201641. (It would be large patch...) Cheers, Yasumasa On 2020/04/01 19:05, David Holmes wrote: > On 1/04/2020 11:02 am, Yasumasa Suenaga wrote: >> Thanks Dan and Serguei! >> >> I added a comment for this to JDK-8201641. >> >> David, can you share Bug ID for thread-to-thread handshake? >> I want to record it to JDK-8201641 as a blocker. > > https://bugs.openjdk.java.net/browse/JDK-8240918 > > I heard the RFR could be as soon as tomorrow :) > > Cheers, > David > >> >> Yasumasa >> >> >> On 2020/04/01 1:59, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> Yes, this works needs to be done. >>> I'll take look at you webrev. >>> >>> Thanks, >>> Serguei >>> >>> On 3/31/20 07:41, Daniel D. Daugherty wrote: >>>> Add Robbin to this thread... >>>> >>>> >>>> This reminded of the following RFE that Robbin filed: >>>> >>>> ??? JDK-8201641 JVMTI: GetThreadListStackTraces should use Thread-Local Handshakes >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8201641 >>>> >>>> We could update 8201641 to include everything that Yasumasa-san is requesting. >>>> Would be a good place to track it... >>>> >>>> Dan >>>> >>>> >>>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> On 2020/03/31 19:16, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Many JVMTI functions uses VM Operation to get information. However some of them need to stop only one thread - they don't need to stop all threads. >>>>>>> So I think we can use Thread Local Handshake as this webrev. It is example for GetOneCurrentContendedMonitor(). >>>>>> >>>>>> True, but at the moment handshakes involve the VMThread. There is work being done to support direct thread-to-thread handshakes and once that is done this kind of conversion should be more easily done. It might be worth waiting for that. >>>>> >>>>> Thanks, I will be back to this topic when thread-to-thread handshake is done. >>>>> I wondered at first why VMThread involves handshake. Its improvement is welcome for me ;) >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>>> >>>>>> An observation, it seems to me that calling_thread is not used when this is not a VMOperation. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> Also I think we can replace following VM Operations to Thread Local Handshake: >>>>>>> >>>>>>> class VM_GetCurrentLocation >>>>>>> class VM_EnterInterpOnlyMode >>>>>>> class VM_UpdateForPopTopFrame >>>>>>> class VM_SetFramePop >>>>>>> class VM_GetOwnedMonitorInfo >>>>>>> class VM_GetCurrentContendedMonitor >>>>>>> class VM_GetFrameCount >>>>>>> class VM_GetFrameLocation >>>>>>> >>>>>>> What do you think? >>>>>>> It it is acceptable, I will file it to JBS and send review request. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>> >>> From coleen.phillimore at oracle.com Wed Apr 1 14:05:39 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 1 Apr 2020 10:05:39 -0400 Subject: Discussion about fixing deprecation in jdk.hotspot.agent In-Reply-To: <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> References: <1916207b-de97-1f25-f93c-8830025fad62@oracle.com> <113dd83a-82a3-88fc-8f31-fe9bfd00c12c@oracle.com> <12e28226-136b-3391-ca01-e9e04058a2a8@oracle.com> <71739959-0aaf-c973-10d2-36f4295ddc37@oracle.com> <1cc556ce-67ed-1e6f-ee53-36d8227d0e1e@oracle.com> <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> Message-ID: On 4/1/20 6:22 AM, Kevin Walls wrote: > Hi Coleen and all - > > Given the choice I'd ask that we don't remove attach/detach because it > limits the scope of what a clhsdb can do in future. Commands like > jstack are a one-shot operation.? A Tool like clhsdb is ideally more > flexible than that. > > The SA is (I suggest) "too static" in its "there is one VM" approach, > so we can't write a Tool that attaches to multiple VMs. If we remove > attach/detach, it could not even gather information in a series of > requests.? This is not going to be in the product any time soon, and > maybe never, but it doesn't look right that we cut off such experiments. > > Removing the Observer, yes would imply making detach into detach and > exit.? I think the clhsdb "attach" command would still work (once > only!) but is odd without detach (so do we make "bin/jhsdb clhsdb" > require parameters...). > > It looks like this changes the direction of the Tools in order to > remove the deprecation warnings. > > Magnus' webrev > http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01/ > does add/duplicate some code, but I like it for keeping things working > 8-) Thanks for answering this before I went out for review.? It's another 1000 lines to maintain, but at least it doesn't duplicate hotspot code. Coleen > > Thanks > Kevin > > > On 31/03/2020 22:20, coleen.phillimore at oracle.com wrote: >> >> >> On 3/31/20 4:55 PM, Chris Plummer wrote: >>> On 3/31/20 1:32 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 3/31/20 12:19 PM, Poonam Parhar wrote: >>>>> Hello Coleen, >>>>> >>>>> Does the removal of this code only impact the 'reattach' >>>>> functionality, and it does not affect any commands available in >>>>> 'clhsdb' once it is attached to a core file? If that's true, then >>>>> I think it should be okay to remove this code. >>>> >>>> Hi Poonam,? Thank you for answering. Yes, this patch only removes >>>> the reattach functionality.? I tried out the other clhsdb commands >>>> from your wiki page, and they worked fine, including object and >>>> heap inspection. >>> I'm trying to understand exactly when all these static initializes >>> are triggered. Is it only after you do an attach? >>> >>> The implementation of clhsdb reattach is exactly the same as doing a >>> detach followed by an attach to the same process. I'm not sure how >>> much value it has, but I think in general the removal of this code >>> means you can't detach and then attach to anything, even a different >>> pid. So "detach" might as well become "detach-and-exit", because >>> your clhsdb session is dead once you detach. Do we really want to do >>> this? >> >> Well, that was my question. It seems like you could just exit and >> start up jhsdb again and that's more like something someone would do >> just as easily.? Given the use cases that we've seen from sustaining, >> this appears to be unneeded functionality. >> >> The original mail was proposing adding more code to work around the >> deprecation messages.? It seems like more code should not be added >> for something that is unused. >> >> thanks, >> Coleen >> >>> >>> Chris >>>> >>>> Thanks, >>>> Coleen >>>>> >>>>> Thanks, >>>>> Poonam >>>>> >>>>> On 3/31/20 5:34 AM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> To answer my own question, this functionality is used to allow >>>>>> detach/reattach from {cl}hsdb.? Which seems to work on linux but >>>>>> not windows with this code removed. >>>>>> >>>>>> The next question is whether this is useful functionality to >>>>>> justify all this code (900+ and this new code that Magnus has >>>>>> added).? Can't you just exit and restart the clhsdb process on >>>>>> the core file or process? >>>>>> >>>>>> For the record, this is me playing with python to remove this code. >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2020/01/webrev/index.html >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 3/30/20 3:04 PM, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> I was wondering why this is needed when debugging a core file, >>>>>>> which is the key thing we need the SA for: >>>>>>> >>>>>>> ? /** This is used by both the debugger and any runtime system. >>>>>>> It is >>>>>>> ????? the basic mechanism by which classes which mimic >>>>>>> underlying VM >>>>>>> ????? functionality cause themselves to be initialized. The given >>>>>>> ????? observer will be notified (with arguments (null, null)) >>>>>>> when the >>>>>>> ????? VM is re-initialized, as well as when it registers itself >>>>>>> with >>>>>>> ????? the VM. */ >>>>>>> ? public static void registerVMInitializedObserver(Observer o) { >>>>>>> ??? vmInitializedObservers.add(o); >>>>>>> ??? o.update(null, null); >>>>>>> ? } >>>>>>> >>>>>>> It seems like if it isn't needed, we shouldn't add these classes >>>>>>> and remove their use. >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> On 3/30/20 8:14 AM, Magnus Ihse Bursie wrote: >>>>>>>> No opinions on this? >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>> On 2020-03-25 23:34, Magnus Ihse Bursie wrote: >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> As a follow-up to the ongoing review for JDK-8241618, I have >>>>>>>>> also looked at fixing the deprecation warnings in >>>>>>>>> jdk.hotspot.agent. These fall in three broad categories: >>>>>>>>> >>>>>>>>> * Deprecation of the boxing type constructors (e.g. "new >>>>>>>>> Integer(42)"). >>>>>>>>> >>>>>>>>> * Deprecation of java.util.Observer and Observable. >>>>>>>>> >>>>>>>>> * The rest (mostly Class.newInstance(), and a few number of >>>>>>>>> other odd deprecations) >>>>>>>>> >>>>>>>>> The first category is trivial to fix. The last category need >>>>>>>>> some special discussion. But the overwhelming majority of >>>>>>>>> deprecation warnings come from the use of Observer and >>>>>>>>> Observable. This really dwarfs anything else, and needs to be >>>>>>>>> handled first, otherwise it's hard to even spot the other issues. >>>>>>>>> >>>>>>>>> My analysis of the situation is that the deprecation of >>>>>>>>> Observer and Observable seems a bit harsh, from the PoV of >>>>>>>>> jdk.hotspot.agent. Sure, it might be limited, but I think it >>>>>>>>> does exactly what is needed here. So the migration suggested >>>>>>>>> in Observable (java.beans or java.util.concurrent) seems >>>>>>>>> overkill. If there are genuine threading issues at play here, >>>>>>>>> this assumption might be wrong, and then maybe going the >>>>>>>>> j.u.c. route is correct. >>>>>>>>> >>>>>>>>> But if that's not, the main goal should be to stay with the >>>>>>>>> current implementation. One way to do this is to sprinkle the >>>>>>>>> code with @SuppressWarning. But I think a better way would be >>>>>>>>> to just implement our own Observer and Observable. After all, >>>>>>>>> the classes are trivial. >>>>>>>>> >>>>>>>>> I've made a mock-up of this solution, were I just copied the >>>>>>>>> java.util.Observer and Observable, and removed the deprecation >>>>>>>>> annotations. The only thing needed for the rest of the code is >>>>>>>>> to make sure we import these; I've done this for three >>>>>>>>> arbitrarily selected classes just to show what the change >>>>>>>>> would typically look like. Here's the mock-up: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01 >>>>>>>>> >>>>>>>>> Let me know what you think. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> From Alan.Bateman at oracle.com Wed Apr 1 14:26:08 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Apr 2020 15:26:08 +0100 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <940c6907-612e-8744-376c-5362991d4a42@oracle.com> Message-ID: On 31/03/2020 20:25, Mandy Chung wrote: > Alex's feedback:? rename isHiddenClass to isHidden as it can be a > hidden class or interface. > > `isLocalClass` and `sAnonymousClass` are correct because the Java > language only has local classes and anon classes, not local interfaces > or anon. interfaces.? `isHidden` is like `isSynthetic`, it could be a > class or interface. > > Although isHiddenClass seems clearer, I'm okay to rename it to > `isHidden`. I went through the java.base changes in webrev.03-delta. The rename to isHidden and the updated javadoc looks good. There are a few additional drive-by updates to the javadoc, including isSynthetic, they all look good too. Maybe I missed it going by, but why is the isHidden check in the field offset methods on sun.misc.Unsafe rather than the internal Unsafe? -Alan. From mandy.chung at oracle.com Wed Apr 1 17:42:57 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Apr 2020 10:42:57 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <940c6907-612e-8744-376c-5362991d4a42@oracle.com> Message-ID: On 4/1/20 7:26 AM, Alan Bateman wrote: > Maybe I missed it going by, but why is the isHidden check in the field > offset methods on sun.misc.Unsafe rather than the internal Unsafe? The reflection and VarHandle implementation uses jdk.internal.misc.Unsafe to do field access (both read and write). For fields of a hidden declaring class, Field::get works on final and non-final fields.? Field::set will work on non-final fields and throw IAE on final fields.?? That's why no change to the internal Unsafe to support reflective field access. The check in the field offset methods in `sun.misc.Unsafe` intends to constrain the existing use of jdk.unsupported unsafe field offset methods to existing classes but not hidden classes (perhaps same to apply to inline classes) moving toward "trusted non-instance finals". Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Apr 1 18:21:48 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 1 Apr 2020 11:21:48 -0700 Subject: RFR: 8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified In-Reply-To: <8B98C7C4-C2BD-4E21-B79B-CDAD9C1C2E97@oracle.com> References: <96a10c0a-83d1-5f17-5426-217e3647ffc3@oracle.com> <89BA7F8A-000C-4C59-AC04-2DF595F7634E@oracle.com> <197eeb11-8328-7d07-3fa0-03494155d3c9@oracle.com> <47425e6e-a7ee-5ef5-0285-fcf5289becda@oracle.com> <042D1C56-75E3-40B9-8259-035C9A13C13B@oracle.com> <47cba4c6-233d-84a9-1d89-b40e3c974c08@oracle.com> <8bcf232e-e05c-98ae-767f-26adf18ad3fd@oracle.com> <8d0cfc5c-f622-2ac9-aecc-8d398f6d3f2e@oracle.com> <8B98C7C4-C2BD-4E21-B79B-CDAD9C1C2E97@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Apr 1 20:01:15 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 1 Apr 2020 13:01:15 -0700 Subject: Discussion about fixing deprecation in jdk.hotspot.agent In-Reply-To: <1b03ec6c-aa7a-859b-1bdf-f061a948e6f0@oracle.com> References: <1916207b-de97-1f25-f93c-8830025fad62@oracle.com> <113dd83a-82a3-88fc-8f31-fe9bfd00c12c@oracle.com> <12e28226-136b-3391-ca01-e9e04058a2a8@oracle.com> <71739959-0aaf-c973-10d2-36f4295ddc37@oracle.com> <1cc556ce-67ed-1e6f-ee53-36d8227d0e1e@oracle.com> <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> <1b03ec6c-aa7a-859b-1bdf-f061a948e6f0@oracle.com> Message-ID: <94f4fc22-630e-4603-d777-b7a642a81c04@oracle.com> On 4/1/20 5:13 AM, Magnus Ihse Bursie wrote: > > > On 2020-04-01 12:22, Kevin Walls wrote: >> Hi Coleen and all - >> >> Given the choice I'd ask that we don't remove attach/detach because >> it limits the scope of what a clhsdb can do in future. Commands like >> jstack are a one-shot operation.? A Tool like clhsdb is ideally more >> flexible than that. >> >> The SA is (I suggest) "too static" in its "there is one VM" approach, >> so we can't write a Tool that attaches to multiple VMs. If we remove >> attach/detach, it could not even gather information in a series of >> requests.? This is not going to be in the product any time soon, and >> maybe never, but it doesn't look right that we cut off such experiments. >> >> Removing the Observer, yes would imply making detach into detach and >> exit.? I think the clhsdb "attach" command would still work (once >> only!) but is odd without detach (so do we make "bin/jhsdb clhsdb" >> require parameters...). >> >> It looks like this changes the direction of the Tools in order to >> remove the deprecation warnings. >> >> Magnus' webrev >> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01/ >> does add/duplicate some code, but I like it for keeping things >> working 8-) > > Here's an updated version of that approach that minimizes the amount > of new code: > > http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.03 > > The difference is that I do not duplicate the classes themselves, I > just subclass them to get a single point where the @SuppressWarnings > can be put. The only change needed in the rest of the files is to make > sure we import these classes instead of the ones in java.util. > HI Magnus, I think at this time this is probably the best approach. It's just two new SA classes that are simple subclasses of Observer and Observable, and a bunch new imports in any file that references them, right? I would just suggest adding a comment to these two classes to indicate why this is being done. thanks, Chris > /Magnus > >> >> >> Thanks >> Kevin >> >> >> On 31/03/2020 22:20, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 3/31/20 4:55 PM, Chris Plummer wrote: >>>> On 3/31/20 1:32 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 3/31/20 12:19 PM, Poonam Parhar wrote: >>>>>> Hello Coleen, >>>>>> >>>>>> Does the removal of this code only impact the 'reattach' >>>>>> functionality, and it does not affect any commands available in >>>>>> 'clhsdb' once it is attached to a core file? If that's true, then >>>>>> I think it should be okay to remove this code. >>>>> >>>>> Hi Poonam,? Thank you for answering. Yes, this patch only removes >>>>> the reattach functionality.? I tried out the other clhsdb commands >>>>> from your wiki page, and they worked fine, including object and >>>>> heap inspection. >>>> I'm trying to understand exactly when all these static initializes >>>> are triggered. Is it only after you do an attach? >>>> >>>> The implementation of clhsdb reattach is exactly the same as doing >>>> a detach followed by an attach to the same process. I'm not sure >>>> how much value it has, but I think in general the removal of this >>>> code means you can't detach and then attach to anything, even a >>>> different pid. So "detach" might as well become "detach-and-exit", >>>> because your clhsdb session is dead once you detach. Do we really >>>> want to do this? >>> >>> Well, that was my question. It seems like you could just exit and >>> start up jhsdb again and that's more like something someone would do >>> just as easily.? Given the use cases that we've seen from >>> sustaining, this appears to be unneeded functionality. >>> >>> The original mail was proposing adding more code to work around the >>> deprecation messages.? It seems like more code should not be added >>> for something that is unused. >>> >>> thanks, >>> Coleen >>> >>>> >>>> Chris >>>>> >>>>> Thanks, >>>>> Coleen >>>>>> >>>>>> Thanks, >>>>>> Poonam >>>>>> >>>>>> On 3/31/20 5:34 AM, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> To answer my own question, this functionality is used to allow >>>>>>> detach/reattach from {cl}hsdb.? Which seems to work on linux but >>>>>>> not windows with this code removed. >>>>>>> >>>>>>> The next question is whether this is useful functionality to >>>>>>> justify all this code (900+ and this new code that Magnus has >>>>>>> added).? Can't you just exit and restart the clhsdb process on >>>>>>> the core file or process? >>>>>>> >>>>>>> For the record, this is me playing with python to remove this code. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2020/01/webrev/index.html >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 3/30/20 3:04 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> >>>>>>>> I was wondering why this is needed when debugging a core file, >>>>>>>> which is the key thing we need the SA for: >>>>>>>> >>>>>>>> ? /** This is used by both the debugger and any runtime system. >>>>>>>> It is >>>>>>>> ????? the basic mechanism by which classes which mimic >>>>>>>> underlying VM >>>>>>>> ????? functionality cause themselves to be initialized. The given >>>>>>>> ????? observer will be notified (with arguments (null, null)) >>>>>>>> when the >>>>>>>> ????? VM is re-initialized, as well as when it registers itself >>>>>>>> with >>>>>>>> ????? the VM. */ >>>>>>>> ? public static void registerVMInitializedObserver(Observer o) { >>>>>>>> ??? vmInitializedObservers.add(o); >>>>>>>> ??? o.update(null, null); >>>>>>>> ? } >>>>>>>> >>>>>>>> It seems like if it isn't needed, we shouldn't add these >>>>>>>> classes and remove their use. >>>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 3/30/20 8:14 AM, Magnus Ihse Bursie wrote: >>>>>>>>> No opinions on this? >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> On 2020-03-25 23:34, Magnus Ihse Bursie wrote: >>>>>>>>>> Hi everyone, >>>>>>>>>> >>>>>>>>>> As a follow-up to the ongoing review for JDK-8241618, I have >>>>>>>>>> also looked at fixing the deprecation warnings in >>>>>>>>>> jdk.hotspot.agent. These fall in three broad categories: >>>>>>>>>> >>>>>>>>>> * Deprecation of the boxing type constructors (e.g. "new >>>>>>>>>> Integer(42)"). >>>>>>>>>> >>>>>>>>>> * Deprecation of java.util.Observer and Observable. >>>>>>>>>> >>>>>>>>>> * The rest (mostly Class.newInstance(), and a few number of >>>>>>>>>> other odd deprecations) >>>>>>>>>> >>>>>>>>>> The first category is trivial to fix. The last category need >>>>>>>>>> some special discussion. But the overwhelming majority of >>>>>>>>>> deprecation warnings come from the use of Observer and >>>>>>>>>> Observable. This really dwarfs anything else, and needs to be >>>>>>>>>> handled first, otherwise it's hard to even spot the other >>>>>>>>>> issues. >>>>>>>>>> >>>>>>>>>> My analysis of the situation is that the deprecation of >>>>>>>>>> Observer and Observable seems a bit harsh, from the PoV of >>>>>>>>>> jdk.hotspot.agent. Sure, it might be limited, but I think it >>>>>>>>>> does exactly what is needed here. So the migration suggested >>>>>>>>>> in Observable (java.beans or java.util.concurrent) seems >>>>>>>>>> overkill. If there are genuine threading issues at play here, >>>>>>>>>> this assumption might be wrong, and then maybe going the >>>>>>>>>> j.u.c. route is correct. >>>>>>>>>> >>>>>>>>>> But if that's not, the main goal should be to stay with the >>>>>>>>>> current implementation. One way to do this is to sprinkle the >>>>>>>>>> code with @SuppressWarning. But I think a better way would be >>>>>>>>>> to just implement our own Observer and Observable. After all, >>>>>>>>>> the classes are trivial. >>>>>>>>>> >>>>>>>>>> I've made a mock-up of this solution, were I just copied the >>>>>>>>>> java.util.Observer and Observable, and removed the >>>>>>>>>> deprecation annotations. The only thing needed for the rest >>>>>>>>>> of the code is to make sure we import these; I've done this >>>>>>>>>> for three arbitrarily selected classes just to show what the >>>>>>>>>> change would typically look like. Here's the mock-up: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Let me know what you think. >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> > From serguei.spitsyn at oracle.com Wed Apr 1 21:19:13 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 1 Apr 2020 14:19:13 -0700 Subject: RFR: 8241530: com/sun/jdi tests fail due to network issues on OSX 10.15 In-Reply-To: References: <84D85D3D-AFCA-42BD-BD02-35604E462D5F@oracle.com> Message-ID: <17833356-c963-ee65-c7c8-f4a8c8c8c5f2@oracle.com> Hi Daniil, LGTM++ Thanks, Serguei On 3/30/20 13:06, Alex Menkov wrote: > Looks good. > > --alex > > On 03/30/2020 12:43, Daniil Titov wrote: >> Please review the change [1] that fixes the failure of >> com/sun/jdi/JdwpListenTest.java >> and com/sun/jdi/JdwpAttachTest.java tests on OSX 10.15. >> >> The problem here is the similar to the one solved in [4] by >> additional filtering >> ? of unusual network interfaces in the test library class >> jdk.test.lib.NetworkConfiguration. >> However,? the failing com/sun/jdi tests do not use >> jdk.test.lib.NetworkConfiguration and >> Instead do repeat the same logic themselves. >> >> The fix changes these tests to start using >> jdk.test.lib.NetworkConfiguration to find all local addresses. >> >> Initially the issue [2] also included 3 other failing tests from >> sun/management/jdp package, but these tests fail >> for a different reason so I moved them in the new issue [3] and >> updated the ProblemList.txt? for them. >> >> >> [1] Webrev: http://cr.openjdk.java.net/~dtitov/8241530/webrev.01/ >> [2] Jira Issue: https://bugs.openjdk.java.net/browse/JDK-8241530 >> [3] https://bugs.openjdk.java.net/browse/JDK-8241865 >> [4] https://bugs.openjdk.java.net/browse/JDK-8241336 >> >> Thank you, >> Daniil >> >> From leonid.mesnik at oracle.com Wed Apr 1 21:47:57 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Wed, 1 Apr 2020 14:47:57 -0700 Subject: RFR: 8240698: LingeredApp does not pass getTestJavaOpts() to the children process if vmArguments is already specified In-Reply-To: References: <96a10c0a-83d1-5f17-5426-217e3647ffc3@oracle.com> <89BA7F8A-000C-4C59-AC04-2DF595F7634E@oracle.com> <197eeb11-8328-7d07-3fa0-03494155d3c9@oracle.com> <47425e6e-a7ee-5ef5-0285-fcf5289becda@oracle.com> <042D1C56-75E3-40B9-8259-035C9A13C13B@oracle.com> <47cba4c6-233d-84a9-1d89-b40e3c974c08@oracle.com> <8bcf232e-e05c-98ae-767f-26adf18ad3fd@oracle.com> <8d0cfc5c-f622-2ac9-aecc-8d398f6d3f2e@oracle.com> <8B98C7C4-C2BD-4E21-B79B-CDAD9C1C2E97@oracle.com> Message-ID: <62E9CBA4-EB56-4A34-9527-4DAAC45116E4@oracle.com> Thank you for review. Filed https://bugs.openjdk.java.net/browse/JDK-8242009 for issue with passing arguments into debugger/tools processes. Leonid > On Apr 1, 2020, at 11:21 AM, Chris Plummer wrote: > > Hi Leonid, > > Looks good. Thanks for cleaning this up! > > Chris > > On 3/31/20 4:12 PM, Leonid Mesnik wrote: >> Here is new webrev: >> http://cr.openjdk.java.net/~lmesnik/8240698/webrev.03/ >> >> The only difference is updated startApp() method and it's comments: >> http://cr.openjdk.java.net/~lmesnik/8240698/webrev.03/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html >> >> Leonid >> >>> On Mar 31, 2020, at 1:32 PM, Chris Plummer > wrote: >>> >>> On 3/31/20 12:09 PM, Leonid Mesnik wrote: >>>> Hi >>>> >>>> On 3/30/20 9:43 PM, Chris Plummer wrote: >>>>> Hi Leonid, >>>>> >>>>> On 3/30/20 5:42 PM, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> See my comments inline. I will update webrev after go through all your comments. >>>>>> >>>>>> >>>>>> On 3/30/20 11:39 AM, Chris Plummer wrote: >>>>>>> Hi Leonid, >>>>>>> >>>>>>> I haven't gone through all the tests yet. I've accumulated enough questions that I'd like to see them answered or addressed before I continue on. >>>>>>> >>>>>>> This isn't directly related to your changes, but I noticed that users of JDKToolLauncher do nothing to make sure that default test options are used. This means we are never running these tools with the test options being specified with the jtreg run. Is that a bug or intentional? >>>>>> >>>>>> Which "default test options" do you mean? We have 2 properties to set JVM options. The idea is to pass test.vm.opts to ALL java processes and test.java.opts to only tested processes if applicable. Usually, for example we don't want to run jcmd with -Xcomp. test.vm.opts was used (a long time ago) for options like '-d32/-d64' on Solaris where JVM don't start without choosing correct version. Also, it is used to reduce maximum heap for all JVM instances when tests are running concurrently. >>>>>> >>>>>> So, probably test.vm.opts (or test.vm.tools.opts) should be added by JDKToolLauncher but not test.java.opts. It is separate topic, there are a lot of launchers which ignore test.vm.opts now. >>>>> I always get confused about which set of options these properties represent, but basically I'm suggesting that if for example we are doing a -Xcomp run in mach5, JDKToolLauncher (at least in some cases) should be launched with this option. I think this is what you get from Utils.getTestJavaOpts(),. >>>>> >>>>> For example the SA tests use JDKToolLauncher.createUsingTestJDK("jhsdb"). jhsdb is what is really being tested here, and it should be launched with the test vm options. Currently we launch the target process with these options, which is probably also a good idea. Also we aren't too concerned with the options that the test itself is run with, although I'm guessing they also get run with the test java opts. So we have 3 processes here: >>>>> - jhsdb, which should be getting test java opts but is not >>>>> - the target process, which should be getting test java opts and currently is >>>>> - the test itself, where options don't really matter, but is getting passed test java opts >>>>> >>>>> However, you could argue that tests like jinfo, jstack, and jcmd, all of which use the Attach API and the bulk of the work is done on the target process, are not that concerned with the options passed to the command, but do want the options passed to the target process. >>>> >>>> Well, it is a good question if we want to run jhsdb tool itself with additional slow options like Xcomp. Does it help us to improve coverage? IIRC the original idea of adding test.java/vm.opts was to don't waste time executing javac and debuggers in slow mode on SPARC. >>>> >>>> Anyway, it is a separate question which is out of scope of this change. We might want to review all debugger/debugee tests to find better way to deal with this. >>> Might be good to get an RFE filed for this. >>>> >>>>>> >>>>>>> >>>>>>> In the problem lists, is it necessary to list the test multiple times with #id0, #id1, etc, or could you list it just once and leave that part off. It seems very error prone. Also, changing tests like ClhsdbFindPC, ClhsdbJstack, and ClhsdbScanOops to split out the testing in this manner seems completely unrelated to this CR, especially when the tests do not even contain any changes related to the CR. >>>>>> >>>>>> I think, that these chages are related. The startApp(...) was updated so some test combinations become invalid or redundant. >>>>>> >>>>>> ClhsdbFindPC and ClhsdbJstack were always run twice. Now, when test options passed in test it is not needed to run it twice when Xcomp is already set by user. >>>>>> >>>>> Ok. I see now that the second test run, which is the non -Xcomp run, adds '@requires vm.compMode != "Xcomp"'. But this also is strange. The first test run, which does not have the @requires and is the one that makes LingeredApp launch with -Xcomp, will always run whether or not it is an -Xcomp test run. So it will run as part of the a regular test run and as part of a -Xcomp test run. The only difference between the two is the -Xcomp run will also run the test with -Xcomp, but that's not really needed (I think it will also end up passing -Xcomp to the target processs twice). Perhaps '@requires vm.compMode == "Xcomp"' should be used for the first test run, but that means it no longer gets run until later tiers when we use -Xcomp. Why not revert it back to a single test, but also add '@requires vm.compMode != "Xcomp"'. Then it gets run both ways in an early tier and not run during the -Xcomp run, which isn't really needed. >>>> >>>> There several flag which are executed with Xcomp only: "-XX:-DoEscapeAnalysis", "-XX:-UseBiasedLocking", "-XX:+DeoptimizeALot" where this test is going to be skipped. So we never run test with these options. >>>> >>>> The original idea is to run test with given options and with added Xcomp. I left logic the same and only skip run with "Xcomp" when it is set already by user. I agree that we have some duplication here and it could be improved, but it could be done separately. If you are ok with this let me file separate RFE for this. >>> Ok. >>>> >>>>> >>>>>> ClhsdbScanOops is fixed to don't allow to run incompatible GC combination. >>>>> Ok >>>>>> >>>>>> So I should update these tests by splitting them or change them to startAppExactJvmOpts() if we wan't continue to ignore user-given test options. >>>>> I don't think I was suggesting removing user-given test options. I don't see why you would. >>>> >>>> I just wanted to say that these tests are affected by my changes and should be fixed anyway. >>> Ok. >>> >>> So I think the one change you agreed to make is have the default be to append test vm opts rather than prepend them. Let me know when you have a new webrev. >>> >>> thanks, >>> >>> Chris >>>> >>>> Leonid >>>> >>>>>> >>>>>> It seems that #idN are required by jtreg now, otherwise it just run test. >>>>> Ok. >>>>>> >>>>>>> >>>>>>> 426 public static LingeredApp startApp(String... additionalJvmOpts) throws IOException { >>>>>>> >>>>>>> The default test opts are appended to additionalJvmOpts, and if you want prepended you need to call Utils.prependTestJavaOpts(). I would have thought the opposite would be more desirable and expected default behavior. Why did you choose this way? I also find it somewhat confusing that there is even a default mode for where the additionalJvmOpts go. Maybe it would be best to have startAppAppendJvmArgs() and startAppPrependJvmArgs() just to make it explicit. This would also be in line with the existing startAppExactJvmOpts(). >>>>>>> >>>>>> I've chosen the most popular usage, which was Utils.appendTestJavaOpts. But I agree, that it would be better to change it to prepend. Thanks for pointing to this. >>>>>> >>>>>> I don't want to add startAppAppendJvmArgs()/startAppPrependJvmArgs() to don't complicate all things. I think that startApp() should be used in the cases when test vm options really shouldn't interfere with user-provided options or overwrite them. So basically the behavior is the same as for ProcessTools.createJavaProcessBuilder(true, ...) and jtreg itself. >>>>>> >>>>> Ok. >>>>>> >>>>>>> Is ClhsdbFindPC correct. It used to use just use -Xcomp or -Xint, ignoring any default test opts. You've fixed it to include the default test opts, but the are appended, possibly overriding the -Xcomp or -Xint. Don't we want the default test opts prepended? Same for ClhsdbJstack. >>>>>> >>>>>> The idea is to don't mix Xcomp and Xmixed/Xint using requires filter. However ClhsdbFindPC might override Xint with Xmixed if it is set explicitly. Switching to prepending will fix it. >>>>> Yes, that's what I was thinking and one reason I thought that should be default behavior. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>>> >>>>>> Leonid >>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 3/25/20 2:31 PM, Leonid Mesnik wrote: >>>>>>>> >>>>>>>> Igor, Stefan, Ioi >>>>>>>> >>>>>>>> Thank you for your feedback. >>>>>>>> >>>>>>>> Filed https://bugs.openjdk.java.net/browse/JDK-8241624 To change @run main... to @run driver. >>>>>>>> >>>>>>>> Test ClhsdbJstack.java is updated. >>>>>>>> >>>>>>>> Still waiting for review from SVC team. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~lmesnik/8240698/webrev.02/ >>>>>>>> >>>>>>>> Leonid >>>>>>>> >>>>>>>> On 3/25/20 12:46 PM, Igor Ignatyev wrote: >>>>>>>>> Hi Leonid, >>>>>>>>> >>>>>>>>> not related related to your patch (but yet somewhat made more obvious by it), it seems all (or at least almost all) the tests which use?LingeredApp should be run in "driver" mode as they just orchestrate execution of other JVMs, so running them w/ main (let alone main/othervm) just wastes time, test/hotspot/jtreg/serviceability/sa/ClhsdbJstack.java#id1, for example, will now executed w/ Xcomp which will make it very slow for no reasons. since you already got your hands dirty w/ these tests, could you please file an RFE to sort this out and list all the affected tests there? >>>>>>>>> >>>>>>>>> re: the patch, could you please update ClhsdbJstack.java test not to be run w/ Xcomp and follow the same pattern you used in other tests (e.g.?ClhsdbScanOops) ? other than that it looks fine to me, I however wouldn't be able to tell if all svc tests continue to do that they were supposed to, so I'd prefer for someone from svc team to?chime in. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> -- Igor >>>>>>>>> >>>>>>>>>> On Mar 25, 2020, at 12:01 PM, Leonid Mesnik >> wrote: >>>>>>>>>> >>>>>>>>>> Added Ioi, who also proposed new version of startAppVmOpts. >>>>>>>>>> >>>>>>>>>> Please find new webrev: http://cr.openjdk.java.net/~lmesnik/8240698/webrev.01/ >>>>>>>>>> >>>>>>>>>> Renamed startAppVmOpts/runAppVmOpts to "startAppExactJvmOpts/runAppExactJvmOpts" is used. It should make very clear that this method doesn't use any of test.java.opts, test.vm.opts. >>>>>>>>>> >>>>>>>>>> Also, I fixed test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java metnioned by Igor, and removed null pointer check as Ioi suggested in startApp method. >>>>>>>>>> >>>>>>>>>> + public static void startApp(LingeredApp theApp, String... additionalJvmOpts) throws IOException { >>>>>>>>>> + startAppExactJvmOpts(theApp, Utils.appendTestJavaOpts(additionalJvmOpts)); >>>>>>>>>> + } >>>>>>>>>> >>>>>>>>>> Leonid >>>>>>>>>> >>>>>>>>>> On 3/25/20 10:14 AM, Stefan Karlsson wrote: >>>>>>>>>>> On 2020-03-25 17:40, Igor Ignatyev wrote: >>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>> >>>>>>>>>>>> I have briefly looked at the patch, a few comments so far: >>>>>>>>>>>> >>>>>>>>>>>> test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java: >>>>>>>>>>>> ? - at L#114, could you please call static method using class name (as the opposite of using instance)? or was it meant to be theApp.runAppVmOpts(vmArgs) ? >>>>>>>>>>>> >>>>>>>>>>>> test/lib/jdk/test/lib/apps/LingeredApp.java: >>>>>>>>>>>> - it seems that code indent of startApp(LingeredApp, String[]) isn't correct >>>>>>>>>>>> - I don't like startAppVmOpts name, but unfortunately don't have a better suggestion (yet) >>>>>>>>>>> >>>>>>>>>>> I was going to say the same. Jtreg has the concept of "java options" and "vm options". We have had a fair share of bugs and wasted time when tests have been using the "vm options" part (VM_OPTIONS, test.vm.options, etc), and we've been moving away from using that way to pass options. I recently cleaned up some of this with: >>>>>>>>>>> >>>>>>>>>>> 8237111: LingeredApp should be started with getTestJavaOpts >>>>>>>>>>> >>>>>>>>>>> Because of this, I would prefer if we used a name that doesn't include "VmOpts", because it's too alike the other concept. Some suggestions: >>>>>>>>>>> ?startAppJavaOptions >>>>>>>>>>> ?startAppUsingJavaOptions >>>>>>>>>>> ?startAppWithJavaOptions >>>>>>>>>>> ?startAppExactJavaOptions >>>>>>>>>>> ?startAppJvmOptions >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> StefanK >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> -- Igor >>>>>>>>>>>> >>>>>>>>>>>>> On Mar 25, 2020, at 8:55 AM, Leonid Mesnik > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> Could you please review following fix which change LingeredApp to prepend vm options to java/vm.test.opts when startApp is used and provide startAppVmOpts to override options completely. >>>>>>>>>>>>> >>>>>>>>>>>>> The intention is to avoid issue like in this bug where test/jtreg options were ignored by tests. Also I fixed some tests where intention was to append vm options rather than to override them. >>>>>>>>>>>>> >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~lmesnik/8240698/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8240698 >>>>>>>>>>>>> >>>>>>>>>>>>> Leonid >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Wed Apr 1 22:16:13 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 1 Apr 2020 18:16:13 -0400 Subject: Discussion about fixing deprecation in jdk.hotspot.agent In-Reply-To: <94f4fc22-630e-4603-d777-b7a642a81c04@oracle.com> References: <1916207b-de97-1f25-f93c-8830025fad62@oracle.com> <113dd83a-82a3-88fc-8f31-fe9bfd00c12c@oracle.com> <12e28226-136b-3391-ca01-e9e04058a2a8@oracle.com> <71739959-0aaf-c973-10d2-36f4295ddc37@oracle.com> <1cc556ce-67ed-1e6f-ee53-36d8227d0e1e@oracle.com> <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> <1b03ec6c-aa7a-859b-1bdf-f061a948e6f0@oracle.com> <94f4fc22-630e-4603-d777-b7a642a81c04@oracle.com> Message-ID: <8c60cddc-46c0-75d2-8560-bb61da08dc1f@oracle.com> On 4/1/20 4:01 PM, Chris Plummer wrote: > On 4/1/20 5:13 AM, Magnus Ihse Bursie wrote: >> >> >> On 2020-04-01 12:22, Kevin Walls wrote: >>> Hi Coleen and all - >>> >>> Given the choice I'd ask that we don't remove attach/detach because >>> it limits the scope of what a clhsdb can do in future. Commands like >>> jstack are a one-shot operation.? A Tool like clhsdb is ideally more >>> flexible than that. >>> >>> The SA is (I suggest) "too static" in its "there is one VM" >>> approach, so we can't write a Tool that attaches to multiple VMs. If >>> we remove attach/detach, it could not even gather information in a >>> series of requests.? This is not going to be in the product any time >>> soon, and maybe never, but it doesn't look right that we cut off >>> such experiments. >>> >>> Removing the Observer, yes would imply making detach into detach and >>> exit.? I think the clhsdb "attach" command would still work (once >>> only!) but is odd without detach (so do we make "bin/jhsdb clhsdb" >>> require parameters...). >>> >>> It looks like this changes the direction of the Tools in order to >>> remove the deprecation warnings. >>> >>> Magnus' webrev >>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01/ >>> does add/duplicate some code, but I like it for keeping things >>> working 8-) >> >> Here's an updated version of that approach that minimizes the amount >> of new code: >> >> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.03 >> >> The difference is that I do not duplicate the classes themselves, I >> just subclass them to get a single point where the @SuppressWarnings >> can be put. The only change needed in the rest of the files is to >> make sure we import these classes instead of the ones in java.util. >> > HI Magnus, > > I think at this time this is probably the best approach. It's just two > new SA classes that are simple subclasses of Observer and Observable, > and a bunch new imports in any file that references them, right? I > would just suggest adding a comment to these two classes to indicate > why this is being done. > When I was looking at this, most of the files import the java.util version of Observer and Observable: import java.util.Observable; import java.util.Observer; If you load the subclass, then these don't have to be changed in all the other files? Coleen > thanks, > > Chris >> /Magnus >> >>> >>> >>> Thanks >>> Kevin >>> >>> >>> On 31/03/2020 22:20, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 3/31/20 4:55 PM, Chris Plummer wrote: >>>>> On 3/31/20 1:32 PM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> >>>>>> On 3/31/20 12:19 PM, Poonam Parhar wrote: >>>>>>> Hello Coleen, >>>>>>> >>>>>>> Does the removal of this code only impact the 'reattach' >>>>>>> functionality, and it does not affect any commands available in >>>>>>> 'clhsdb' once it is attached to a core file? If that's true, >>>>>>> then I think it should be okay to remove this code. >>>>>> >>>>>> Hi Poonam,? Thank you for answering. Yes, this patch only removes >>>>>> the reattach functionality.? I tried out the other clhsdb >>>>>> commands from your wiki page, and they worked fine, including >>>>>> object and heap inspection. >>>>> I'm trying to understand exactly when all these static initializes >>>>> are triggered. Is it only after you do an attach? >>>>> >>>>> The implementation of clhsdb reattach is exactly the same as doing >>>>> a detach followed by an attach to the same process. I'm not sure >>>>> how much value it has, but I think in general the removal of this >>>>> code means you can't detach and then attach to anything, even a >>>>> different pid. So "detach" might as well become "detach-and-exit", >>>>> because your clhsdb session is dead once you detach. Do we really >>>>> want to do this? >>>> >>>> Well, that was my question. It seems like you could just exit and >>>> start up jhsdb again and that's more like something someone would >>>> do just as easily.? Given the use cases that we've seen from >>>> sustaining, this appears to be unneeded functionality. >>>> >>>> The original mail was proposing adding more code to work around the >>>> deprecation messages.? It seems like more code should not be added >>>> for something that is unused. >>>> >>>> thanks, >>>> Coleen >>>> >>>>> >>>>> Chris >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>>> >>>>>>> Thanks, >>>>>>> Poonam >>>>>>> >>>>>>> On 3/31/20 5:34 AM, coleen.phillimore at oracle.com wrote: >>>>>>>> >>>>>>>> To answer my own question, this functionality is used to allow >>>>>>>> detach/reattach from {cl}hsdb.? Which seems to work on linux >>>>>>>> but not windows with this code removed. >>>>>>>> >>>>>>>> The next question is whether this is useful functionality to >>>>>>>> justify all this code (900+ and this new code that Magnus has >>>>>>>> added).? Can't you just exit and restart the clhsdb process on >>>>>>>> the core file or process? >>>>>>>> >>>>>>>> For the record, this is me playing with python to remove this >>>>>>>> code. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2020/01/webrev/index.html >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 3/30/20 3:04 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>> >>>>>>>>> I was wondering why this is needed when debugging a core file, >>>>>>>>> which is the key thing we need the SA for: >>>>>>>>> >>>>>>>>> ? /** This is used by both the debugger and any runtime >>>>>>>>> system. It is >>>>>>>>> ????? the basic mechanism by which classes which mimic >>>>>>>>> underlying VM >>>>>>>>> ????? functionality cause themselves to be initialized. The given >>>>>>>>> ????? observer will be notified (with arguments (null, null)) >>>>>>>>> when the >>>>>>>>> ????? VM is re-initialized, as well as when it registers >>>>>>>>> itself with >>>>>>>>> ????? the VM. */ >>>>>>>>> ? public static void registerVMInitializedObserver(Observer o) { >>>>>>>>> ??? vmInitializedObservers.add(o); >>>>>>>>> ??? o.update(null, null); >>>>>>>>> ? } >>>>>>>>> >>>>>>>>> It seems like if it isn't needed, we shouldn't add these >>>>>>>>> classes and remove their use. >>>>>>>>> >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 3/30/20 8:14 AM, Magnus Ihse Bursie wrote: >>>>>>>>>> No opinions on this? >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> On 2020-03-25 23:34, Magnus Ihse Bursie wrote: >>>>>>>>>>> Hi everyone, >>>>>>>>>>> >>>>>>>>>>> As a follow-up to the ongoing review for JDK-8241618, I have >>>>>>>>>>> also looked at fixing the deprecation warnings in >>>>>>>>>>> jdk.hotspot.agent. These fall in three broad categories: >>>>>>>>>>> >>>>>>>>>>> * Deprecation of the boxing type constructors (e.g. "new >>>>>>>>>>> Integer(42)"). >>>>>>>>>>> >>>>>>>>>>> * Deprecation of java.util.Observer and Observable. >>>>>>>>>>> >>>>>>>>>>> * The rest (mostly Class.newInstance(), and a few number of >>>>>>>>>>> other odd deprecations) >>>>>>>>>>> >>>>>>>>>>> The first category is trivial to fix. The last category need >>>>>>>>>>> some special discussion. But the overwhelming majority of >>>>>>>>>>> deprecation warnings come from the use of Observer and >>>>>>>>>>> Observable. This really dwarfs anything else, and needs to >>>>>>>>>>> be handled first, otherwise it's hard to even spot the other >>>>>>>>>>> issues. >>>>>>>>>>> >>>>>>>>>>> My analysis of the situation is that the deprecation of >>>>>>>>>>> Observer and Observable seems a bit harsh, from the PoV of >>>>>>>>>>> jdk.hotspot.agent. Sure, it might be limited, but I think it >>>>>>>>>>> does exactly what is needed here. So the migration suggested >>>>>>>>>>> in Observable (java.beans or java.util.concurrent) seems >>>>>>>>>>> overkill. If there are genuine threading issues at play >>>>>>>>>>> here, this assumption might be wrong, and then maybe going >>>>>>>>>>> the j.u.c. route is correct. >>>>>>>>>>> >>>>>>>>>>> But if that's not, the main goal should be to stay with the >>>>>>>>>>> current implementation. One way to do this is to sprinkle >>>>>>>>>>> the code with @SuppressWarning. But I think a better way >>>>>>>>>>> would be to just implement our own Observer and Observable. >>>>>>>>>>> After all, the classes are trivial. >>>>>>>>>>> >>>>>>>>>>> I've made a mock-up of this solution, were I just copied the >>>>>>>>>>> java.util.Observer and Observable, and removed the >>>>>>>>>>> deprecation annotations. The only thing needed for the rest >>>>>>>>>>> of the code is to make sure we import these; I've done this >>>>>>>>>>> for three arbitrarily selected classes just to show what the >>>>>>>>>>> change would typically look like. Here's the mock-up: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Let me know what you think. >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >> > > From david.holmes at oracle.com Wed Apr 1 23:29:10 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 09:29:10 +1000 Subject: Discussion about fixing deprecation in jdk.hotspot.agent In-Reply-To: <8c60cddc-46c0-75d2-8560-bb61da08dc1f@oracle.com> References: <1916207b-de97-1f25-f93c-8830025fad62@oracle.com> <113dd83a-82a3-88fc-8f31-fe9bfd00c12c@oracle.com> <12e28226-136b-3391-ca01-e9e04058a2a8@oracle.com> <71739959-0aaf-c973-10d2-36f4295ddc37@oracle.com> <1cc556ce-67ed-1e6f-ee53-36d8227d0e1e@oracle.com> <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> <1b03ec6c-aa7a-859b-1bdf-f061a948e6f0@oracle.com> <94f4fc22-630e-4603-d777-b7a642a81c04@oracle.com> <8c60cddc-46c0-75d2-8560-bb61da08dc1f@oracle.com> Message-ID: On 2/04/2020 8:16 am, coleen.phillimore at oracle.com wrote: > On 4/1/20 4:01 PM, Chris Plummer wrote: >> On 4/1/20 5:13 AM, Magnus Ihse Bursie wrote: >>> >>> >>> On 2020-04-01 12:22, Kevin Walls wrote: >>>> Hi Coleen and all - >>>> >>>> Given the choice I'd ask that we don't remove attach/detach because >>>> it limits the scope of what a clhsdb can do in future. Commands like >>>> jstack are a one-shot operation.? A Tool like clhsdb is ideally more >>>> flexible than that. >>>> >>>> The SA is (I suggest) "too static" in its "there is one VM" >>>> approach, so we can't write a Tool that attaches to multiple VMs. If >>>> we remove attach/detach, it could not even gather information in a >>>> series of requests.? This is not going to be in the product any time >>>> soon, and maybe never, but it doesn't look right that we cut off >>>> such experiments. >>>> >>>> Removing the Observer, yes would imply making detach into detach and >>>> exit.? I think the clhsdb "attach" command would still work (once >>>> only!) but is odd without detach (so do we make "bin/jhsdb clhsdb" >>>> require parameters...). >>>> >>>> It looks like this changes the direction of the Tools in order to >>>> remove the deprecation warnings. >>>> >>>> Magnus' webrev >>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01/ >>>> does add/duplicate some code, but I like it for keeping things >>>> working 8-) >>> >>> Here's an updated version of that approach that minimizes the amount >>> of new code: >>> >>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.03 >>> >>> The difference is that I do not duplicate the classes themselves, I >>> just subclass them to get a single point where the @SuppressWarnings >>> can be put. The only change needed in the rest of the files is to >>> make sure we import these classes instead of the ones in java.util. >>> >> HI Magnus, >> >> I think at this time this is probably the best approach. It's just two >> new SA classes that are simple subclasses of Observer and Observable, >> and a bunch new imports in any file that references them, right? I >> would just suggest adding a comment to these two classes to indicate >> why this is being done. >> > > When I was looking at this, most of the files import the java.util > version of Observer and Observable: > > import java.util.Observable; > import java.util.Observer; > > If you load the subclass, then these don't have to be changed in all the > other files? Yes something not right here. For example I see in sun/jvm/hotspot/runtime/Threads.java import java.util.*; which is an import-on-demand statement that would allow Observer and Observable to be found. But then later we have: import sun.jvm.hotspot.utilities.*; which would be an import-on-demand statement that would allow the new Observer and Observable to be found. Consequently a simple reference to Observer or Observable will be ambiguous and should result in an a compile-time error! There would have to be an explicit import using import sun.jvm.hotspot.utilities.Observable; import sun.jvm.hotspot.utilities.Observer; to negate the import-on-demand of java.util.* David ---- > Coleen > >> thanks, >> >> Chris >>> /Magnus >>> >>>> >>>> >>>> Thanks >>>> Kevin >>>> >>>> >>>> On 31/03/2020 22:20, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 3/31/20 4:55 PM, Chris Plummer wrote: >>>>>> On 3/31/20 1:32 PM, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> >>>>>>> On 3/31/20 12:19 PM, Poonam Parhar wrote: >>>>>>>> Hello Coleen, >>>>>>>> >>>>>>>> Does the removal of this code only impact the 'reattach' >>>>>>>> functionality, and it does not affect any commands available in >>>>>>>> 'clhsdb' once it is attached to a core file? If that's true, >>>>>>>> then I think it should be okay to remove this code. >>>>>>> >>>>>>> Hi Poonam,? Thank you for answering. Yes, this patch only removes >>>>>>> the reattach functionality.? I tried out the other clhsdb >>>>>>> commands from your wiki page, and they worked fine, including >>>>>>> object and heap inspection. >>>>>> I'm trying to understand exactly when all these static initializes >>>>>> are triggered. Is it only after you do an attach? >>>>>> >>>>>> The implementation of clhsdb reattach is exactly the same as doing >>>>>> a detach followed by an attach to the same process. I'm not sure >>>>>> how much value it has, but I think in general the removal of this >>>>>> code means you can't detach and then attach to anything, even a >>>>>> different pid. So "detach" might as well become "detach-and-exit", >>>>>> because your clhsdb session is dead once you detach. Do we really >>>>>> want to do this? >>>>> >>>>> Well, that was my question. It seems like you could just exit and >>>>> start up jhsdb again and that's more like something someone would >>>>> do just as easily.? Given the use cases that we've seen from >>>>> sustaining, this appears to be unneeded functionality. >>>>> >>>>> The original mail was proposing adding more code to work around the >>>>> deprecation messages.? It seems like more code should not be added >>>>> for something that is unused. >>>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Chris >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Poonam >>>>>>>> >>>>>>>> On 3/31/20 5:34 AM, coleen.phillimore at oracle.com wrote: >>>>>>>>> >>>>>>>>> To answer my own question, this functionality is used to allow >>>>>>>>> detach/reattach from {cl}hsdb.? Which seems to work on linux >>>>>>>>> but not windows with this code removed. >>>>>>>>> >>>>>>>>> The next question is whether this is useful functionality to >>>>>>>>> justify all this code (900+ and this new code that Magnus has >>>>>>>>> added).? Can't you just exit and restart the clhsdb process on >>>>>>>>> the core file or process? >>>>>>>>> >>>>>>>>> For the record, this is me playing with python to remove this >>>>>>>>> code. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~coleenp/2020/01/webrev/index.html >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 3/30/20 3:04 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>> >>>>>>>>>> I was wondering why this is needed when debugging a core file, >>>>>>>>>> which is the key thing we need the SA for: >>>>>>>>>> >>>>>>>>>> ? /** This is used by both the debugger and any runtime >>>>>>>>>> system. It is >>>>>>>>>> ????? the basic mechanism by which classes which mimic >>>>>>>>>> underlying VM >>>>>>>>>> ????? functionality cause themselves to be initialized. The given >>>>>>>>>> ????? observer will be notified (with arguments (null, null)) >>>>>>>>>> when the >>>>>>>>>> ????? VM is re-initialized, as well as when it registers >>>>>>>>>> itself with >>>>>>>>>> ????? the VM. */ >>>>>>>>>> ? public static void registerVMInitializedObserver(Observer o) { >>>>>>>>>> ??? vmInitializedObservers.add(o); >>>>>>>>>> ??? o.update(null, null); >>>>>>>>>> ? } >>>>>>>>>> >>>>>>>>>> It seems like if it isn't needed, we shouldn't add these >>>>>>>>>> classes and remove their use. >>>>>>>>>> >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> On 3/30/20 8:14 AM, Magnus Ihse Bursie wrote: >>>>>>>>>>> No opinions on this? >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> On 2020-03-25 23:34, Magnus Ihse Bursie wrote: >>>>>>>>>>>> Hi everyone, >>>>>>>>>>>> >>>>>>>>>>>> As a follow-up to the ongoing review for JDK-8241618, I have >>>>>>>>>>>> also looked at fixing the deprecation warnings in >>>>>>>>>>>> jdk.hotspot.agent. These fall in three broad categories: >>>>>>>>>>>> >>>>>>>>>>>> * Deprecation of the boxing type constructors (e.g. "new >>>>>>>>>>>> Integer(42)"). >>>>>>>>>>>> >>>>>>>>>>>> * Deprecation of java.util.Observer and Observable. >>>>>>>>>>>> >>>>>>>>>>>> * The rest (mostly Class.newInstance(), and a few number of >>>>>>>>>>>> other odd deprecations) >>>>>>>>>>>> >>>>>>>>>>>> The first category is trivial to fix. The last category need >>>>>>>>>>>> some special discussion. But the overwhelming majority of >>>>>>>>>>>> deprecation warnings come from the use of Observer and >>>>>>>>>>>> Observable. This really dwarfs anything else, and needs to >>>>>>>>>>>> be handled first, otherwise it's hard to even spot the other >>>>>>>>>>>> issues. >>>>>>>>>>>> >>>>>>>>>>>> My analysis of the situation is that the deprecation of >>>>>>>>>>>> Observer and Observable seems a bit harsh, from the PoV of >>>>>>>>>>>> jdk.hotspot.agent. Sure, it might be limited, but I think it >>>>>>>>>>>> does exactly what is needed here. So the migration suggested >>>>>>>>>>>> in Observable (java.beans or java.util.concurrent) seems >>>>>>>>>>>> overkill. If there are genuine threading issues at play >>>>>>>>>>>> here, this assumption might be wrong, and then maybe going >>>>>>>>>>>> the j.u.c. route is correct. >>>>>>>>>>>> >>>>>>>>>>>> But if that's not, the main goal should be to stay with the >>>>>>>>>>>> current implementation. One way to do this is to sprinkle >>>>>>>>>>>> the code with @SuppressWarning. But I think a better way >>>>>>>>>>>> would be to just implement our own Observer and Observable. >>>>>>>>>>>> After all, the classes are trivial. >>>>>>>>>>>> >>>>>>>>>>>> I've made a mock-up of this solution, were I just copied the >>>>>>>>>>>> java.util.Observer and Observable, and removed the >>>>>>>>>>>> deprecation annotations. The only thing needed for the rest >>>>>>>>>>>> of the code is to make sure we import these; I've done this >>>>>>>>>>>> for three arbitrarily selected classes just to show what the >>>>>>>>>>>> change would typically look like. Here's the mock-up: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Let me know what you think. >>>>>>>>>>>> >>>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >> >> > From chris.plummer at oracle.com Thu Apr 2 00:21:51 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 1 Apr 2020 17:21:51 -0700 Subject: Discussion about fixing deprecation in jdk.hotspot.agent In-Reply-To: References: <1916207b-de97-1f25-f93c-8830025fad62@oracle.com> <113dd83a-82a3-88fc-8f31-fe9bfd00c12c@oracle.com> <12e28226-136b-3391-ca01-e9e04058a2a8@oracle.com> <71739959-0aaf-c973-10d2-36f4295ddc37@oracle.com> <1cc556ce-67ed-1e6f-ee53-36d8227d0e1e@oracle.com> <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> <1b03ec6c-aa7a-859b-1bdf-f061a948e6f0@oracle.com> <94f4fc22-630e-4603-d777-b7a642a81c04@oracle.com> <8c60cddc-46c0-75d2-8560-bb61da08dc1f@oracle.com> Message-ID: On 4/1/20 4:29 PM, David Holmes wrote: > On 2/04/2020 8:16 am, coleen.phillimore at oracle.com wrote: >> On 4/1/20 4:01 PM, Chris Plummer wrote: >>> On 4/1/20 5:13 AM, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2020-04-01 12:22, Kevin Walls wrote: >>>>> Hi Coleen and all - >>>>> >>>>> Given the choice I'd ask that we don't remove attach/detach >>>>> because it limits the scope of what a clhsdb can do in future. >>>>> Commands like jstack are a one-shot operation.? A Tool like clhsdb >>>>> is ideally more flexible than that. >>>>> >>>>> The SA is (I suggest) "too static" in its "there is one VM" >>>>> approach, so we can't write a Tool that attaches to multiple VMs. >>>>> If we remove attach/detach, it could not even gather information >>>>> in a series of requests.? This is not going to be in the product >>>>> any time soon, and maybe never, but it doesn't look right that we >>>>> cut off such experiments. >>>>> >>>>> Removing the Observer, yes would imply making detach into detach >>>>> and exit.? I think the clhsdb "attach" command would still work >>>>> (once only!) but is odd without detach (so do we make "bin/jhsdb >>>>> clhsdb" require parameters...). >>>>> >>>>> It looks like this changes the direction of the Tools in order to >>>>> remove the deprecation warnings. >>>>> >>>>> Magnus' webrev >>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01/ >>>>> does add/duplicate some code, but I like it for keeping things >>>>> working 8-) >>>> >>>> Here's an updated version of that approach that minimizes the >>>> amount of new code: >>>> >>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.03 >>>> >>>> The difference is that I do not duplicate the classes themselves, I >>>> just subclass them to get a single point where the >>>> @SuppressWarnings can be put. The only change needed in the rest of >>>> the files is to make sure we import these classes instead of the >>>> ones in java.util. >>>> >>> HI Magnus, >>> >>> I think at this time this is probably the best approach. It's just >>> two new SA classes that are simple subclasses of Observer and >>> Observable, and a bunch new imports in any file that references >>> them, right? I would just suggest adding a comment to these two >>> classes to indicate why this is being done. >>> >> >> When I was looking at this, most of the files import the java.util >> version of Observer and Observable: >> >> import java.util.Observable; >> import java.util.Observer; >> >> If you load the subclass, then these don't have to be changed in all >> the other files? > > Yes something not right here. For example I see in > > sun/jvm/hotspot/runtime/Threads.java > > import java.util.*; > > which is an import-on-demand statement that would allow Observer and > Observable to be found. But then later we have: > > import sun.jvm.hotspot.utilities.*; > > which would be an import-on-demand statement that would allow the new > Observer and Observable to be found. > > Consequently a simple reference to Observer or Observable will be > ambiguous and should result in an a compile-time error! > > There would have to be an explicit import using > > import sun.jvm.hotspot.utilities.Observable; > import sun.jvm.hotspot.utilities.Observer; > > to negate the import-on-demand of java.util.* Magnus only fixed 3 of the SA files as an example. I think the plan is to add the above import to every file that uses Observer/Observable. But as you point out, some already import java.util.Observable/Observable, and you can't have both, so in that case the new import should replace the old one. Chris > > David > ---- > >> Coleen >> >>> thanks, >>> >>> Chris >>>> /Magnus >>>> >>>>> >>>>> >>>>> Thanks >>>>> Kevin >>>>> >>>>> >>>>> On 31/03/2020 22:20, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> >>>>>> On 3/31/20 4:55 PM, Chris Plummer wrote: >>>>>>> On 3/31/20 1:32 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 3/31/20 12:19 PM, Poonam Parhar wrote: >>>>>>>>> Hello Coleen, >>>>>>>>> >>>>>>>>> Does the removal of this code only impact the 'reattach' >>>>>>>>> functionality, and it does not affect any commands available >>>>>>>>> in 'clhsdb' once it is attached to a core file? If that's >>>>>>>>> true, then I think it should be okay to remove this code. >>>>>>>> >>>>>>>> Hi Poonam,? Thank you for answering. Yes, this patch only >>>>>>>> removes the reattach functionality.? I tried out the other >>>>>>>> clhsdb commands from your wiki page, and they worked fine, >>>>>>>> including object and heap inspection. >>>>>>> I'm trying to understand exactly when all these static >>>>>>> initializes are triggered. Is it only after you do an attach? >>>>>>> >>>>>>> The implementation of clhsdb reattach is exactly the same as >>>>>>> doing a detach followed by an attach to the same process. I'm >>>>>>> not sure how much value it has, but I think in general the >>>>>>> removal of this code means you can't detach and then attach to >>>>>>> anything, even a different pid. So "detach" might as well become >>>>>>> "detach-and-exit", because your clhsdb session is dead once you >>>>>>> detach. Do we really want to do this? >>>>>> >>>>>> Well, that was my question. It seems like you could just exit and >>>>>> start up jhsdb again and that's more like something someone would >>>>>> do just as easily.? Given the use cases that we've seen from >>>>>> sustaining, this appears to be unneeded functionality. >>>>>> >>>>>> The original mail was proposing adding more code to work around >>>>>> the deprecation messages.? It seems like more code should not be >>>>>> added for something that is unused. >>>>>> >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Chris >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Poonam >>>>>>>>> >>>>>>>>> On 3/31/20 5:34 AM, coleen.phillimore at oracle.com wrote: >>>>>>>>>> >>>>>>>>>> To answer my own question, this functionality is used to >>>>>>>>>> allow detach/reattach from {cl}hsdb. Which seems to work on >>>>>>>>>> linux but not windows with this code removed. >>>>>>>>>> >>>>>>>>>> The next question is whether this is useful functionality to >>>>>>>>>> justify all this code (900+ and this new code that Magnus has >>>>>>>>>> added).? Can't you just exit and restart the clhsdb process >>>>>>>>>> on the core file or process? >>>>>>>>>> >>>>>>>>>> For the record, this is me playing with python to remove this >>>>>>>>>> code. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~coleenp/2020/01/webrev/index.html >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> On 3/30/20 3:04 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>>> >>>>>>>>>>> I was wondering why this is needed when debugging a core >>>>>>>>>>> file, which is the key thing we need the SA for: >>>>>>>>>>> >>>>>>>>>>> ? /** This is used by both the debugger and any runtime >>>>>>>>>>> system. It is >>>>>>>>>>> ????? the basic mechanism by which classes which mimic >>>>>>>>>>> underlying VM >>>>>>>>>>> ????? functionality cause themselves to be initialized. The >>>>>>>>>>> given >>>>>>>>>>> ????? observer will be notified (with arguments (null, >>>>>>>>>>> null)) when the >>>>>>>>>>> ????? VM is re-initialized, as well as when it registers >>>>>>>>>>> itself with >>>>>>>>>>> ????? the VM. */ >>>>>>>>>>> ? public static void registerVMInitializedObserver(Observer >>>>>>>>>>> o) { >>>>>>>>>>> ??? vmInitializedObservers.add(o); >>>>>>>>>>> ??? o.update(null, null); >>>>>>>>>>> ? } >>>>>>>>>>> >>>>>>>>>>> It seems like if it isn't needed, we shouldn't add these >>>>>>>>>>> classes and remove their use. >>>>>>>>>>> >>>>>>>>>>> Coleen >>>>>>>>>>> >>>>>>>>>>> On 3/30/20 8:14 AM, Magnus Ihse Bursie wrote: >>>>>>>>>>>> No opinions on this? >>>>>>>>>>>> >>>>>>>>>>>> /Magnus >>>>>>>>>>>> >>>>>>>>>>>> On 2020-03-25 23:34, Magnus Ihse Bursie wrote: >>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>> >>>>>>>>>>>>> As a follow-up to the ongoing review for JDK-8241618, I >>>>>>>>>>>>> have also looked at fixing the deprecation warnings in >>>>>>>>>>>>> jdk.hotspot.agent. These fall in three broad categories: >>>>>>>>>>>>> >>>>>>>>>>>>> * Deprecation of the boxing type constructors (e.g. "new >>>>>>>>>>>>> Integer(42)"). >>>>>>>>>>>>> >>>>>>>>>>>>> * Deprecation of java.util.Observer and Observable. >>>>>>>>>>>>> >>>>>>>>>>>>> * The rest (mostly Class.newInstance(), and a few number >>>>>>>>>>>>> of other odd deprecations) >>>>>>>>>>>>> >>>>>>>>>>>>> The first category is trivial to fix. The last category >>>>>>>>>>>>> need some special discussion. But the overwhelming >>>>>>>>>>>>> majority of deprecation warnings come from the use of >>>>>>>>>>>>> Observer and Observable. This really dwarfs anything else, >>>>>>>>>>>>> and needs to be handled first, otherwise it's hard to even >>>>>>>>>>>>> spot the other issues. >>>>>>>>>>>>> >>>>>>>>>>>>> My analysis of the situation is that the deprecation of >>>>>>>>>>>>> Observer and Observable seems a bit harsh, from the PoV of >>>>>>>>>>>>> jdk.hotspot.agent. Sure, it might be limited, but I think >>>>>>>>>>>>> it does exactly what is needed here. So the migration >>>>>>>>>>>>> suggested in Observable (java.beans or >>>>>>>>>>>>> java.util.concurrent) seems overkill. If there are genuine >>>>>>>>>>>>> threading issues at play here, this assumption might be >>>>>>>>>>>>> wrong, and then maybe going the j.u.c. route is correct. >>>>>>>>>>>>> >>>>>>>>>>>>> But if that's not, the main goal should be to stay with >>>>>>>>>>>>> the current implementation. One way to do this is to >>>>>>>>>>>>> sprinkle the code with @SuppressWarning. But I think a >>>>>>>>>>>>> better way would be to just implement our own Observer and >>>>>>>>>>>>> Observable. After all, the classes are trivial. >>>>>>>>>>>>> >>>>>>>>>>>>> I've made a mock-up of this solution, were I just copied >>>>>>>>>>>>> the java.util.Observer and Observable, and removed the >>>>>>>>>>>>> deprecation annotations. The only thing needed for the >>>>>>>>>>>>> rest of the code is to make sure we import these; I've >>>>>>>>>>>>> done this for three arbitrarily selected classes just to >>>>>>>>>>>>> show what the change would typically look like. Here's the >>>>>>>>>>>>> mock-up: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Let me know what you think. >>>>>>>>>>>>> >>>>>>>>>>>>> /Magnus >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>> >>> >> From david.holmes at oracle.com Thu Apr 2 00:25:07 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 10:25:07 +1000 Subject: Discussion about fixing deprecation in jdk.hotspot.agent In-Reply-To: References: <1916207b-de97-1f25-f93c-8830025fad62@oracle.com> <113dd83a-82a3-88fc-8f31-fe9bfd00c12c@oracle.com> <12e28226-136b-3391-ca01-e9e04058a2a8@oracle.com> <71739959-0aaf-c973-10d2-36f4295ddc37@oracle.com> <1cc556ce-67ed-1e6f-ee53-36d8227d0e1e@oracle.com> <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> <1b03ec6c-aa7a-859b-1bdf-f061a948e6f0@oracle.com> <94f4fc22-630e-4603-d777-b7a642a81c04@oracle.com> <8c60cddc-46c0-75d2-8560-bb61da08dc1f@oracle.com> Message-ID: On 2/04/2020 10:21 am, Chris Plummer wrote: > On 4/1/20 4:29 PM, David Holmes wrote: >> On 2/04/2020 8:16 am, coleen.phillimore at oracle.com wrote: >>> On 4/1/20 4:01 PM, Chris Plummer wrote: >>>> On 4/1/20 5:13 AM, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2020-04-01 12:22, Kevin Walls wrote: >>>>>> Hi Coleen and all - >>>>>> >>>>>> Given the choice I'd ask that we don't remove attach/detach >>>>>> because it limits the scope of what a clhsdb can do in future. >>>>>> Commands like jstack are a one-shot operation.? A Tool like clhsdb >>>>>> is ideally more flexible than that. >>>>>> >>>>>> The SA is (I suggest) "too static" in its "there is one VM" >>>>>> approach, so we can't write a Tool that attaches to multiple VMs. >>>>>> If we remove attach/detach, it could not even gather information >>>>>> in a series of requests.? This is not going to be in the product >>>>>> any time soon, and maybe never, but it doesn't look right that we >>>>>> cut off such experiments. >>>>>> >>>>>> Removing the Observer, yes would imply making detach into detach >>>>>> and exit.? I think the clhsdb "attach" command would still work >>>>>> (once only!) but is odd without detach (so do we make "bin/jhsdb >>>>>> clhsdb" require parameters...). >>>>>> >>>>>> It looks like this changes the direction of the Tools in order to >>>>>> remove the deprecation warnings. >>>>>> >>>>>> Magnus' webrev >>>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01/ >>>>>> does add/duplicate some code, but I like it for keeping things >>>>>> working 8-) >>>>> >>>>> Here's an updated version of that approach that minimizes the >>>>> amount of new code: >>>>> >>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.03 >>>>> >>>>> The difference is that I do not duplicate the classes themselves, I >>>>> just subclass them to get a single point where the >>>>> @SuppressWarnings can be put. The only change needed in the rest of >>>>> the files is to make sure we import these classes instead of the >>>>> ones in java.util. >>>>> >>>> HI Magnus, >>>> >>>> I think at this time this is probably the best approach. It's just >>>> two new SA classes that are simple subclasses of Observer and >>>> Observable, and a bunch new imports in any file that references >>>> them, right? I would just suggest adding a comment to these two >>>> classes to indicate why this is being done. >>>> >>> >>> When I was looking at this, most of the files import the java.util >>> version of Observer and Observable: >>> >>> import java.util.Observable; >>> import java.util.Observer; >>> >>> If you load the subclass, then these don't have to be changed in all >>> the other files? >> >> Yes something not right here. For example I see in >> >> sun/jvm/hotspot/runtime/Threads.java >> >> import java.util.*; >> >> which is an import-on-demand statement that would allow Observer and >> Observable to be found. But then later we have: >> >> import sun.jvm.hotspot.utilities.*; >> >> which would be an import-on-demand statement that would allow the new >> Observer and Observable to be found. >> >> Consequently a simple reference to Observer or Observable will be >> ambiguous and should result in an a compile-time error! >> >> There would have to be an explicit import using >> >> import sun.jvm.hotspot.utilities.Observable; >> import sun.jvm.hotspot.utilities.Observer; >> >> to negate the import-on-demand of java.util.* > Magnus only fixed 3 of the SA files as an example. Okay - that was not at all clear from the email. Thanks, David ----- I think the plan is > to add the above import to every file that uses Observer/Observable. But > as you point out, some already import java.util.Observable/Observable, > and you can't have both, so in that case the new import should replace > the old one. > > Chris >> >> David >> ---- >> >>> Coleen >>> >>>> thanks, >>>> >>>> Chris >>>>> /Magnus >>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> Kevin >>>>>> >>>>>> >>>>>> On 31/03/2020 22:20, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> >>>>>>> On 3/31/20 4:55 PM, Chris Plummer wrote: >>>>>>>> On 3/31/20 1:32 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/31/20 12:19 PM, Poonam Parhar wrote: >>>>>>>>>> Hello Coleen, >>>>>>>>>> >>>>>>>>>> Does the removal of this code only impact the 'reattach' >>>>>>>>>> functionality, and it does not affect any commands available >>>>>>>>>> in 'clhsdb' once it is attached to a core file? If that's >>>>>>>>>> true, then I think it should be okay to remove this code. >>>>>>>>> >>>>>>>>> Hi Poonam,? Thank you for answering. Yes, this patch only >>>>>>>>> removes the reattach functionality.? I tried out the other >>>>>>>>> clhsdb commands from your wiki page, and they worked fine, >>>>>>>>> including object and heap inspection. >>>>>>>> I'm trying to understand exactly when all these static >>>>>>>> initializes are triggered. Is it only after you do an attach? >>>>>>>> >>>>>>>> The implementation of clhsdb reattach is exactly the same as >>>>>>>> doing a detach followed by an attach to the same process. I'm >>>>>>>> not sure how much value it has, but I think in general the >>>>>>>> removal of this code means you can't detach and then attach to >>>>>>>> anything, even a different pid. So "detach" might as well become >>>>>>>> "detach-and-exit", because your clhsdb session is dead once you >>>>>>>> detach. Do we really want to do this? >>>>>>> >>>>>>> Well, that was my question. It seems like you could just exit and >>>>>>> start up jhsdb again and that's more like something someone would >>>>>>> do just as easily.? Given the use cases that we've seen from >>>>>>> sustaining, this appears to be unneeded functionality. >>>>>>> >>>>>>> The original mail was proposing adding more code to work around >>>>>>> the deprecation messages.? It seems like more code should not be >>>>>>> added for something that is unused. >>>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>>> >>>>>>>> Chris >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Poonam >>>>>>>>>> >>>>>>>>>> On 3/31/20 5:34 AM, coleen.phillimore at oracle.com wrote: >>>>>>>>>>> >>>>>>>>>>> To answer my own question, this functionality is used to >>>>>>>>>>> allow detach/reattach from {cl}hsdb. Which seems to work on >>>>>>>>>>> linux but not windows with this code removed. >>>>>>>>>>> >>>>>>>>>>> The next question is whether this is useful functionality to >>>>>>>>>>> justify all this code (900+ and this new code that Magnus has >>>>>>>>>>> added).? Can't you just exit and restart the clhsdb process >>>>>>>>>>> on the core file or process? >>>>>>>>>>> >>>>>>>>>>> For the record, this is me playing with python to remove this >>>>>>>>>>> code. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~coleenp/2020/01/webrev/index.html >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Coleen >>>>>>>>>>> >>>>>>>>>>> On 3/30/20 3:04 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>>>> >>>>>>>>>>>> I was wondering why this is needed when debugging a core >>>>>>>>>>>> file, which is the key thing we need the SA for: >>>>>>>>>>>> >>>>>>>>>>>> ? /** This is used by both the debugger and any runtime >>>>>>>>>>>> system. It is >>>>>>>>>>>> ????? the basic mechanism by which classes which mimic >>>>>>>>>>>> underlying VM >>>>>>>>>>>> ????? functionality cause themselves to be initialized. The >>>>>>>>>>>> given >>>>>>>>>>>> ????? observer will be notified (with arguments (null, >>>>>>>>>>>> null)) when the >>>>>>>>>>>> ????? VM is re-initialized, as well as when it registers >>>>>>>>>>>> itself with >>>>>>>>>>>> ????? the VM. */ >>>>>>>>>>>> ? public static void registerVMInitializedObserver(Observer >>>>>>>>>>>> o) { >>>>>>>>>>>> ??? vmInitializedObservers.add(o); >>>>>>>>>>>> ??? o.update(null, null); >>>>>>>>>>>> ? } >>>>>>>>>>>> >>>>>>>>>>>> It seems like if it isn't needed, we shouldn't add these >>>>>>>>>>>> classes and remove their use. >>>>>>>>>>>> >>>>>>>>>>>> Coleen >>>>>>>>>>>> >>>>>>>>>>>> On 3/30/20 8:14 AM, Magnus Ihse Bursie wrote: >>>>>>>>>>>>> No opinions on this? >>>>>>>>>>>>> >>>>>>>>>>>>> /Magnus >>>>>>>>>>>>> >>>>>>>>>>>>> On 2020-03-25 23:34, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>>> >>>>>>>>>>>>>> As a follow-up to the ongoing review for JDK-8241618, I >>>>>>>>>>>>>> have also looked at fixing the deprecation warnings in >>>>>>>>>>>>>> jdk.hotspot.agent. These fall in three broad categories: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Deprecation of the boxing type constructors (e.g. "new >>>>>>>>>>>>>> Integer(42)"). >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Deprecation of java.util.Observer and Observable. >>>>>>>>>>>>>> >>>>>>>>>>>>>> * The rest (mostly Class.newInstance(), and a few number >>>>>>>>>>>>>> of other odd deprecations) >>>>>>>>>>>>>> >>>>>>>>>>>>>> The first category is trivial to fix. The last category >>>>>>>>>>>>>> need some special discussion. But the overwhelming >>>>>>>>>>>>>> majority of deprecation warnings come from the use of >>>>>>>>>>>>>> Observer and Observable. This really dwarfs anything else, >>>>>>>>>>>>>> and needs to be handled first, otherwise it's hard to even >>>>>>>>>>>>>> spot the other issues. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My analysis of the situation is that the deprecation of >>>>>>>>>>>>>> Observer and Observable seems a bit harsh, from the PoV of >>>>>>>>>>>>>> jdk.hotspot.agent. Sure, it might be limited, but I think >>>>>>>>>>>>>> it does exactly what is needed here. So the migration >>>>>>>>>>>>>> suggested in Observable (java.beans or >>>>>>>>>>>>>> java.util.concurrent) seems overkill. If there are genuine >>>>>>>>>>>>>> threading issues at play here, this assumption might be >>>>>>>>>>>>>> wrong, and then maybe going the j.u.c. route is correct. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But if that's not, the main goal should be to stay with >>>>>>>>>>>>>> the current implementation. One way to do this is to >>>>>>>>>>>>>> sprinkle the code with @SuppressWarning. But I think a >>>>>>>>>>>>>> better way would be to just implement our own Observer and >>>>>>>>>>>>>> Observable. After all, the classes are trivial. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've made a mock-up of this solution, were I just copied >>>>>>>>>>>>>> the java.util.Observer and Observable, and removed the >>>>>>>>>>>>>> deprecation annotations. The only thing needed for the >>>>>>>>>>>>>> rest of the code is to make sure we import these; I've >>>>>>>>>>>>>> done this for three arbitrarily selected classes just to >>>>>>>>>>>>>> show what the change would typically look like. Here's the >>>>>>>>>>>>>> mock-up: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Let me know what you think. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Magnus >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>>> >>> > > From leonid.mesnik at oracle.com Thu Apr 2 02:17:38 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Wed, 1 Apr 2020 19:17:38 -0700 Subject: RFR: 8241456: ThreadRunner shouldn't use Wicket for threads starting synchronization In-Reply-To: <70175e02-2c50-50e7-0646-4fb82be6c768@oracle.com> References: <412d8c29-7742-a138-dc74-8f07def5eeae@oracle.com> <9502df2b-07d1-b1d2-5e66-fce0eb4ac9d7@oracle.com> <12701240-fd7d-560d-8974-ff0be9cafa7e@oracle.com> <70175e02-2c50-50e7-0646-4fb82be6c768@oracle.com> Message-ID: <01083dfc-1a73-4f47-c340-a734868c9e51@oracle.com> Find new version (updated webrev.00 by mistake) http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00/ The moving lock.lock() outside of try is required to don't get IllegalStateException. And avoiding locks in ThreadRunner is needed to avoid OOME. Leonid On 3/26/20 4:41 PM, Leonid Mesnik wrote: > > On 3/26/20 4:29 PM, David Holmes wrote: >> On 27/03/2020 9:16 am, Leonid Mesnik wrote: >>> >>> On 3/26/20 4:06 PM, David Holmes wrote: >>>> Hi Leonid, >>>> >>>> On 27/03/2020 7:39 am, Leonid Mesnik wrote: >>>>> Replying with correct summary. >>>>> >>>>> Leonid >>>>> >>>>> On 3/23/20 8:55 PM, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> Could you please review following fix which update ThreadsRunner >>>>>> to use AtomicInteger/spinOnWait instead of Wicket to synchronize >>>>>> starting of stress test threads. >>>>>> >>>>>> Failing tests allocated all memory by earlier started threads >>>>>> before Lock.unlock is called in the latest threads. So thread >>>>>> might get an OOME exception while trying to release lock and/or >>>>>> get into inconsistent state. >>>> >>>> You have a bug in Wicket: >>>> >>>> +??????? try { >>>> +??????????? lock.lock(); >>>> ... >>>> +??????? } finally { >>>> +??????????? lock.unlock(); >>>> >>>> The lock() has to go outside the try block. That is why you were >>>> getting IllegalMonitorStateExceptions when the lock() threw OOME. >>> Thanks for explanation. But anyway, as I understand locks use memory >>> and might be inconsistent if OOME happened. >> >> They use memory and so lock() can throw OOME, but they are never >> inconsistent. > Ok, I will move lock.lock() outside of try {}. Thanks for explanation. >> >>>> >>>> But the OOME itself is still a problem as it means you can't use >>>> any proper synchronizer. I don't like seeing the spin-loops but in >>>> this code you may have no choice if memory may already be exhausted. >>> >>> It should be really short spin-loop, test only start thread during >>> this loop and don't do anything more. Also, it is done only once for >>> all stress test. The goal is to start thread completely before heap >>> is exhausted. >> >> Okay. I'm somewhat dubious about making these changes in mainline now >> just to support loom. I don't see why we need to care about pinning >> threads in this kind of situation. > > The idea is to add some nsk/share stress tests for virtual threads. > Basically, there are the same tests as existing (gc, sysdict) but > running in virtual threads. And these tests are going to be executed > after loom is integrated. And I want to keep the difference as small > as possible between mainline and loom. > > Leonid > >> >> David >> >>> Leonid >>> >>>> >>>> David >>>> ----- >>>> >>>> >>>>>> >>>>>> The bug was introduced by >>>>>> https://bugs.openjdk.java.net/browse/JDK-8241123 >>>>>> >>>>>> The Atomic works fine for stress test finishing sync. I just >>>>>> didn't expect that tests might OOME while releasing start lock. >>>>>> Verified that tests now don't fail with -Xcomp -server >>>>>> -XX:-TieredCompilation -XX:-UseCompressedOops. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00/ >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8241456 >>>>>> >>>>>> >>>>>> Leonid From david.holmes at oracle.com Thu Apr 2 04:18:26 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 14:18:26 +1000 Subject: RFR: 8241456: ThreadRunner shouldn't use Wicket for threads starting synchronization In-Reply-To: <01083dfc-1a73-4f47-c340-a734868c9e51@oracle.com> References: <412d8c29-7742-a138-dc74-8f07def5eeae@oracle.com> <9502df2b-07d1-b1d2-5e66-fce0eb4ac9d7@oracle.com> <12701240-fd7d-560d-8974-ff0be9cafa7e@oracle.com> <70175e02-2c50-50e7-0646-4fb82be6c768@oracle.com> <01083dfc-1a73-4f47-c340-a734868c9e51@oracle.com> Message-ID: Looks good - thanks Leonid. David On 2/04/2020 12:17 pm, Leonid Mesnik wrote: > Find new version (updated webrev.00 by mistake) > > http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00/ > > The moving lock.lock() outside of try is required to don't get > IllegalStateException. > > And avoiding locks in ThreadRunner is needed to avoid OOME. > > Leonid > > On 3/26/20 4:41 PM, Leonid Mesnik wrote: >> >> On 3/26/20 4:29 PM, David Holmes wrote: >>> On 27/03/2020 9:16 am, Leonid Mesnik wrote: >>>> >>>> On 3/26/20 4:06 PM, David Holmes wrote: >>>>> Hi Leonid, >>>>> >>>>> On 27/03/2020 7:39 am, Leonid Mesnik wrote: >>>>>> Replying with correct summary. >>>>>> >>>>>> Leonid >>>>>> >>>>>> On 3/23/20 8:55 PM, Leonid Mesnik wrote: >>>>>>> Hi >>>>>>> >>>>>>> Could you please review following fix which update ThreadsRunner >>>>>>> to use AtomicInteger/spinOnWait instead of Wicket to synchronize >>>>>>> starting of stress test threads. >>>>>>> >>>>>>> Failing tests allocated all memory by earlier started threads >>>>>>> before Lock.unlock is called in the latest threads. So thread >>>>>>> might get an OOME exception while trying to release lock and/or >>>>>>> get into inconsistent state. >>>>> >>>>> You have a bug in Wicket: >>>>> >>>>> +??????? try { >>>>> +??????????? lock.lock(); >>>>> ... >>>>> +??????? } finally { >>>>> +??????????? lock.unlock(); >>>>> >>>>> The lock() has to go outside the try block. That is why you were >>>>> getting IllegalMonitorStateExceptions when the lock() threw OOME. >>>> Thanks for explanation. But anyway, as I understand locks use memory >>>> and might be inconsistent if OOME happened. >>> >>> They use memory and so lock() can throw OOME, but they are never >>> inconsistent. >> Ok, I will move lock.lock() outside of try {}. Thanks for explanation. >>> >>>>> >>>>> But the OOME itself is still a problem as it means you can't use >>>>> any proper synchronizer. I don't like seeing the spin-loops but in >>>>> this code you may have no choice if memory may already be exhausted. >>>> >>>> It should be really short spin-loop, test only start thread during >>>> this loop and don't do anything more. Also, it is done only once for >>>> all stress test. The goal is to start thread completely before heap >>>> is exhausted. >>> >>> Okay. I'm somewhat dubious about making these changes in mainline now >>> just to support loom. I don't see why we need to care about pinning >>> threads in this kind of situation. >> >> The idea is to add some nsk/share stress tests for virtual threads. >> Basically, there are the same tests as existing (gc, sysdict) but >> running in virtual threads. And these tests are going to be executed >> after loom is integrated. And I want to keep the difference as small >> as possible between mainline and loom. >> >> Leonid >> >>> >>> David >>> >>>> Leonid >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>>> >>>>>>> The bug was introduced by >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8241123 >>>>>>> >>>>>>> The Atomic works fine for stress test finishing sync. I just >>>>>>> didn't expect that tests might OOME while releasing start lock. >>>>>>> Verified that tests now don't fail with -Xcomp -server >>>>>>> -XX:-TieredCompilation -XX:-UseCompressedOops. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00/ >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8241456 >>>>>>> >>>>>>> >>>>>>> Leonid From david.holmes at oracle.com Thu Apr 2 04:52:54 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 14:52:54 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> Message-ID: <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Hi Mandy, On 1/04/2020 1:01 pm, Mandy Chung wrote: > Thanks to the review feedbacks. > > Updated webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ I've had a good look through all the hotspot related changes. All looks good. A few minor comments: src/hotspot/share/ci/ciField.cpp // Trust VM hidden and unsafe anonymous classes. should say // Trust hidden and VM unsafe anonymous classes. // the private API (jdk.internal.misc.Unsafe) s/the/a/ or else change the () to commas or perhaps even better: // the private jdk.internal.misc.Unsafe API, --- src/hotspot/share/ci/ciInstanceKlass.cpp // VM weak hidden and unsafe anonymous classes should say // weak hidden and VM unsafe anonymous classes --- src/hotspot/share/classfile/classLoaderData.hpp ! // the CLDs lifecycle. For example, a non-strong hidden class or an ... ! // Used for weak hidden classes, unsafe anonymous classes and the There is an inconsistency in terminology, so far most code comments refer to "weak hidden" but now you are using "non-strong hidden". ! for an weak hidden s/an/a/ multiple locations --- src/hotspot/share/interpreter/linkResolver.cpp Can you fix one of my comments please (in two places) :) + // For private access check if there was a problem with nest host would read better as: + // For private access see if there was a problem with nest host --- Thanks, David ------ > Delta between webrev.03 and webrev.04: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ > > Summary of changes is: > 1. Update javac to retain the previous behavior when compiling to target > release <= 14 where lambda proxy class is not a nestmate > 2. Rename Class::isHiddenClass to Class::isHidden > 3. Address Joe's feedback on the CSR to document the behavior of the > relevant methods in java.lang.Class for hidden classes > 4. Add test case for unloadable class with nest host error > 5. Add test cases for hidden classes with different kinds of class or > interface > 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class" > 7. Small changes in response to Remi, Coleen, Paul's review comments > 8. Fix copyright headers > 9. Fix @modules in tests > > Most of the changes above have also been reviewed as separate patches. > > Thanks > Mandy > > On 3/26/20 4:57 PM, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area.? Small changes are >> made in javac, VM compiler (intrinsification of Class::isHiddenClass), >> JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized >> state (see specdiff and javadoc below for reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > From mandy.chung at oracle.com Thu Apr 2 05:17:09 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Apr 2020 05:17:09 +0000 (UTC) Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: Hi David, Thanks for the edits to the comments.?? "weak hidden" were missed to be changed to "non-strong hidden".? Here is the patch fixing the comments. diff --git a/src/hotspot/share/ci/ciField.cpp b/src/hotspot/share/ci/ciField.cpp --- a/src/hotspot/share/ci/ciField.cpp +++ b/src/hotspot/share/ci/ciField.cpp @@ -223,8 +223,8 @@ ?????? holder->is_in_package("jdk/internal/foreign") || holder->is_in_package("jdk/incubator/foreign") || ?????? holder->is_in_package("java/lang")) ???? return true; -? // Trust VM hidden and unsafe anonymous classes. They are created via Lookup.defineClass or -? // the private API (jdk.internal.misc.Unsafe) and can't be serialized, so there is no hacking +? // Trust hidden and VM unsafe anonymous classes. They are created via Lookup.defineClass or +? // the private jdk.internal.misc.Unsafe API and can't be serialized, so there is no hacking ?? // of finals going on with them. ?? if (holder->is_hidden() || holder->is_unsafe_anonymous()) ???? return true; diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp b/src/hotspot/share/ci/ciInstanceKlass.cpp --- a/src/hotspot/share/ci/ciInstanceKlass.cpp +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp @@ -76,7 +76,7 @@ ?? oop holder = ik->klass_holder(); ?? if (ik->class_loader_data()->has_class_mirror_holder()) { ???? // Though ciInstanceKlass records class loader oop, it's not enough to keep -??? // VM weak hidden and unsafe anonymous classes alive (loader == NULL). Klass holder should +??? // non-strong hidden class and VM unsafe anonymous classes alive (loader == NULL). Klass holder should ???? // be used instead. It is enough to record a ciObject, since cached elements are never removed ???? // during ciObjectFactory lifetime. ciObjectFactory itself is created for ???? // every compilation and lives for the whole duration of the compilation. diff --git a/src/hotspot/share/classfile/classLoaderData.hpp b/src/hotspot/share/classfile/classLoaderData.hpp --- a/src/hotspot/share/classfile/classLoaderData.hpp +++ b/src/hotspot/share/classfile/classLoaderData.hpp @@ -127,9 +127,10 @@ ?? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS support) ?? int _keep_alive;???????? // if this CLD is kept alive. -?????????????????????????? // Used for weak hidden classes, unsafe anonymous classes and the +?????????????????????????? // Used for non-strong hidden classes, unsafe anonymous classes and the ??????????????????????????? // boot class loader. _keep_alive does not need to be volatile or -?????????????????????????? // atomic since there is one unique CLD per weak hidden or unsafe anonymous class. +?????????????????????????? // atomic since there is one unique CLD per non-strong hidden class +?????????????????????????? // or unsafe anonymous class. ?? volatile int _claim; // non-zero if claimed, for example during GC traces. ??????????????????????? // To avoid applying oop closure more than once. @@ -242,15 +243,15 @@ ?? } ?? // Returns true if this class loader data is for the system class loader. -? // (Note that the class loader data may be for an weak hidden or unsafe anonymous class) +? // (Note that the class loader data may be for a non-strong hidden class or unsafe anonymous class) ?? bool is_system_class_loader_data() const; ?? // Returns true if this class loader data is for the platform class loader. -? // (Note that the class loader data may be for an weak hidden or unsafe anonymous class) +? // (Note that the class loader data may be for a non-strong hidden class or unsafe anonymous class) ?? bool is_platform_class_loader_data() const; ?? // Returns true if this class loader data is for the boot class loader. -? // (Note that the class loader data may be for an weak hidden unsafe anonymous class) +? // (Note that the class loader data may be for a non-strong hidden class or unsafe anonymous class) ?? inline bool is_boot_class_loader_data() const; ?? bool is_builtin_class_loader_data() const; @@ -271,7 +272,7 @@ ???? return _unloading; ?? } -? // Used to refcount an weak hidden or unsafe anonymous class's CLD in order to +? // Used to refcount a non-strong hidden class's or unsafe anonymous class's CLD in order to ?? // indicate their aliveness. ?? void inc_keep_alive(); ?? void dec_keep_alive(); diff --git a/src/hotspot/share/interpreter/linkResolver.cpp b/src/hotspot/share/interpreter/linkResolver.cpp --- a/src/hotspot/share/interpreter/linkResolver.cpp +++ b/src/hotspot/share/interpreter/linkResolver.cpp @@ -611,7 +611,7 @@ ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() ????????????? ); -??? // For private access check if there was a problem with nest host +??? // For private access see if there was a problem with nest host ???? // resolution, and if so report that as part of the message. ???? if (sel_method->is_private()) { ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); @@ -951,7 +951,7 @@ ????????????? (same_module) ? "" : "; ", ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() ????????????? ); -??? // For private access check if there was a problem with nest host +??? // For private access see if there was a problem with nest host ???? // resolution, and if so report that as part of the message. ???? if (fd.is_private()) { ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); Mandy On 4/1/20 9:52 PM, David Holmes wrote: > Hi Mandy, > > On 1/04/2020 1:01 pm, Mandy Chung wrote: >> Thanks to the review feedbacks. >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >> > > I've had a good look through all the hotspot related changes. All > looks good. > > A few minor comments: > > src/hotspot/share/ci/ciField.cpp > > ?? // Trust VM hidden and unsafe anonymous classes. > > should say > > ?? // Trust hidden and VM unsafe anonymous classes. > > > ? // the private API (jdk.internal.misc.Unsafe) > > s/the/a/? or else change the () to commas or perhaps even better: > > ? // the private jdk.internal.misc.Unsafe API, > > --- > > src/hotspot/share/ci/ciInstanceKlass.cpp > > ? // VM weak hidden and unsafe anonymous classes > > should say > > ? // weak hidden and VM unsafe anonymous classes > > --- > > src/hotspot/share/classfile/classLoaderData.hpp > > !? // the CLDs lifecycle.? For example, a non-strong hidden class or an > ... > !? // Used for weak hidden classes, unsafe anonymous classes and the > > There is an inconsistency in terminology, so far most code comments > refer to "weak hidden" but now you are using "non-strong hidden". > > ! for an weak hidden > > s/an/a/?? multiple locations > > --- > > src/hotspot/share/interpreter/linkResolver.cpp > > Can you fix one of my comments please (in two places) :) > > +???? // For private access check if there was a problem with nest host > > would read better as: > > +???? // For private access see if there was a problem with nest host > > --- > > Thanks, > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Apr 2 06:21:10 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 16:21:10 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: Hi Mandy, On 2/04/2020 3:17 pm, Mandy Chung wrote: > Hi David, > > Thanks for the edits to the comments.?? "weak hidden" were missed to be > changed to "non-strong hidden".? Here is the patch fixing the comments. There are 33 cases of "weak hidden" in the patch I reviewed and also some "hidden weak". Should they all be "non-strong hidden" now? In some cases it also appears in variables and associated logic ie.: src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp + _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), I'm not clear how far this terminology change needs to extend ?? Otherwise patch below seems fine. Thanks, David ----- > diff --git a/src/hotspot/share/ci/ciField.cpp > b/src/hotspot/share/ci/ciField.cpp > --- a/src/hotspot/share/ci/ciField.cpp > +++ b/src/hotspot/share/ci/ciField.cpp > @@ -223,8 +223,8 @@ > ?????? holder->is_in_package("jdk/internal/foreign") || > holder->is_in_package("jdk/incubator/foreign") || > ?????? holder->is_in_package("java/lang")) > ???? return true; > -? // Trust VM hidden and unsafe anonymous classes. They are created via > Lookup.defineClass or > -? // the private API (jdk.internal.misc.Unsafe) and can't be > serialized, so there is no hacking > +? // Trust hidden and VM unsafe anonymous classes. They are created via > Lookup.defineClass or > +? // the private jdk.internal.misc.Unsafe API and can't be serialized, > so there is no hacking > ?? // of finals going on with them. > ?? if (holder->is_hidden() || holder->is_unsafe_anonymous()) > ???? return true; > diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp > b/src/hotspot/share/ci/ciInstanceKlass.cpp > --- a/src/hotspot/share/ci/ciInstanceKlass.cpp > +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp > @@ -76,7 +76,7 @@ > ?? oop holder = ik->klass_holder(); > ?? if (ik->class_loader_data()->has_class_mirror_holder()) { > ???? // Though ciInstanceKlass records class loader oop, it's not > enough to keep > -??? // VM weak hidden and unsafe anonymous classes alive (loader == > NULL). Klass holder should > +??? // non-strong hidden class and VM unsafe anonymous classes alive > (loader == NULL). Klass holder should > ???? // be used instead. It is enough to record a ciObject, since > cached elements are never removed > ???? // during ciObjectFactory lifetime. ciObjectFactory itself is > created for > ???? // every compilation and lives for the whole duration of the > compilation. > diff --git a/src/hotspot/share/classfile/classLoaderData.hpp > b/src/hotspot/share/classfile/classLoaderData.hpp > --- a/src/hotspot/share/classfile/classLoaderData.hpp > +++ b/src/hotspot/share/classfile/classLoaderData.hpp > @@ -127,9 +127,10 @@ > ?? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS support) > > ?? int _keep_alive;???????? // if this CLD is kept alive. > -?????????????????????????? // Used for weak hidden classes, unsafe > anonymous classes and the > +?????????????????????????? // Used for non-strong hidden classes, > unsafe anonymous classes and the > ??????????????????????????? // boot class loader. _keep_alive does not > need to be volatile or > -?????????????????????????? // atomic since there is one unique CLD per > weak hidden or unsafe anonymous class. > +?????????????????????????? // atomic since there is one unique CLD per > non-strong hidden class > +?????????????????????????? // or unsafe anonymous class. > > ?? volatile int _claim; // non-zero if claimed, for example during GC > traces. > ??????????????????????? // To avoid applying oop closure more than once. > @@ -242,15 +243,15 @@ > ?? } > > ?? // Returns true if this class loader data is for the system class > loader. > -? // (Note that the class loader data may be for an weak hidden or > unsafe anonymous class) > +? // (Note that the class loader data may be for a non-strong hidden > class or unsafe anonymous class) > ?? bool is_system_class_loader_data() const; > > ?? // Returns true if this class loader data is for the platform class > loader. > -? // (Note that the class loader data may be for an weak hidden or > unsafe anonymous class) > +? // (Note that the class loader data may be for a non-strong hidden > class or unsafe anonymous class) > ?? bool is_platform_class_loader_data() const; > > ?? // Returns true if this class loader data is for the boot class loader. > -? // (Note that the class loader data may be for an weak hidden unsafe > anonymous class) > +? // (Note that the class loader data may be for a non-strong hidden > class or unsafe anonymous class) > ?? inline bool is_boot_class_loader_data() const; > > ?? bool is_builtin_class_loader_data() const; > @@ -271,7 +272,7 @@ > ???? return _unloading; > ?? } > > -? // Used to refcount an weak hidden or unsafe anonymous class's CLD in > order to > +? // Used to refcount a non-strong hidden class's or unsafe anonymous > class's CLD in order to > ?? // indicate their aliveness. > ?? void inc_keep_alive(); > ?? void dec_keep_alive(); > > diff --git a/src/hotspot/share/interpreter/linkResolver.cpp > b/src/hotspot/share/interpreter/linkResolver.cpp > --- a/src/hotspot/share/interpreter/linkResolver.cpp > +++ b/src/hotspot/share/interpreter/linkResolver.cpp > @@ -611,7 +611,7 @@ > ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() > ????????????? ); > > -??? // For private access check if there was a problem with nest host > +??? // For private access see if there was a problem with nest host > ???? // resolution, and if so report that as part of the message. > ???? if (sel_method->is_private()) { > ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); > @@ -951,7 +951,7 @@ > ????????????? (same_module) ? "" : "; ", > ????????????? (same_module) ? "" : sel_klass->class_in_module_of_loader() > ????????????? ); > -??? // For private access check if there was a problem with nest host > +??? // For private access see if there was a problem with nest host > ???? // resolution, and if so report that as part of the message. > ???? if (fd.is_private()) { > ?????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); > > Mandy > > On 4/1/20 9:52 PM, David Holmes wrote: >> Hi Mandy, >> >> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>> Thanks to the review feedbacks. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>> >> >> I've had a good look through all the hotspot related changes. All >> looks good. >> >> A few minor comments: >> >> src/hotspot/share/ci/ciField.cpp >> >> ?? // Trust VM hidden and unsafe anonymous classes. >> >> should say >> >> ?? // Trust hidden and VM unsafe anonymous classes. >> >> >> ? // the private API (jdk.internal.misc.Unsafe) >> >> s/the/a/? or else change the () to commas or perhaps even better: >> >> ? // the private jdk.internal.misc.Unsafe API, >> >> --- >> >> src/hotspot/share/ci/ciInstanceKlass.cpp >> >> ? // VM weak hidden and unsafe anonymous classes >> >> should say >> >> ? // weak hidden and VM unsafe anonymous classes >> >> --- >> >> src/hotspot/share/classfile/classLoaderData.hpp >> >> !? // the CLDs lifecycle.? For example, a non-strong hidden class or an >> ... >> !? // Used for weak hidden classes, unsafe anonymous classes and the >> >> There is an inconsistency in terminology, so far most code comments >> refer to "weak hidden" but now you are using "non-strong hidden". >> >> ! for an weak hidden >> >> s/an/a/?? multiple locations >> >> --- >> >> src/hotspot/share/interpreter/linkResolver.cpp >> >> Can you fix one of my comments please (in two places) :) >> >> +???? // For private access check if there was a problem with nest host >> >> would read better as: >> >> +???? // For private access see if there was a problem with nest host >> >> --- >> >> Thanks, >> David >> > From kevin.walls at oracle.com Thu Apr 2 07:58:10 2020 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 2 Apr 2020 08:58:10 +0100 Subject: Discussion about fixing deprecation in jdk.hotspot.agent In-Reply-To: <1b03ec6c-aa7a-859b-1bdf-f061a948e6f0@oracle.com> References: <1916207b-de97-1f25-f93c-8830025fad62@oracle.com> <113dd83a-82a3-88fc-8f31-fe9bfd00c12c@oracle.com> <12e28226-136b-3391-ca01-e9e04058a2a8@oracle.com> <71739959-0aaf-c973-10d2-36f4295ddc37@oracle.com> <1cc556ce-67ed-1e6f-ee53-36d8227d0e1e@oracle.com> <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> <1b03ec6c-aa7a-859b-1bdf-f061a948e6f0@oracle.com> Message-ID: Thanks Magnus -? I think webrev.03 expanded to change all the imports will keep us all happy for now, Thanks Kevin From suenaga at oss.nttdata.com Thu Apr 2 09:14:04 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 2 Apr 2020 18:14:04 +0900 Subject: Discussion about fixing deprecation in jdk.hotspot.agent In-Reply-To: <1b03ec6c-aa7a-859b-1bdf-f061a948e6f0@oracle.com> References: <1916207b-de97-1f25-f93c-8830025fad62@oracle.com> <113dd83a-82a3-88fc-8f31-fe9bfd00c12c@oracle.com> <12e28226-136b-3391-ca01-e9e04058a2a8@oracle.com> <71739959-0aaf-c973-10d2-36f4295ddc37@oracle.com> <1cc556ce-67ed-1e6f-ee53-36d8227d0e1e@oracle.com> <7c0c8666-c249-e138-2838-18682c646eac@oracle.com> <1b03ec6c-aa7a-859b-1bdf-f061a948e6f0@oracle.com> Message-ID: <10432e07-24c8-c1c4-d3e0-a743a54099ed@oss.nttdata.com> Hi, As other option, we can replace Observe/Observable to other class /interface. AFAICS most of classes which call VM.registerVMInitializedObserver() seems not to use arguments in Observable. For example: VM.registerVMInitializedObserver(() -> initialize(VM.getVM().getTypeDataBase())); or VM.registerVMInitializedObserver(this::initialize); // `initialize` is method reference: Caller would pass TypeDataBase I know it would be bigger change than Magnus's proposal (+ modifying import declarations), but I think it is easier to understand. Thanks, Yasumasa On 2020/04/01 21:13, Magnus Ihse Bursie wrote: > > > On 2020-04-01 12:22, Kevin Walls wrote: >> Hi Coleen and all - >> >> Given the choice I'd ask that we don't remove attach/detach because it limits the scope of what a clhsdb can do in future. Commands like jstack are a one-shot operation.? A Tool like clhsdb is ideally more flexible than that. >> >> The SA is (I suggest) "too static" in its "there is one VM" approach, so we can't write a Tool that attaches to multiple VMs. If we remove attach/detach, it could not even gather information in a series of requests.? This is not going to be in the product any time soon, and maybe never, but it doesn't look right that we cut off such experiments. >> >> Removing the Observer, yes would imply making detach into detach and exit.? I think the clhsdb "attach" command would still work (once only!) but is odd without detach (so do we make "bin/jhsdb clhsdb" require parameters...). >> >> It looks like this changes the direction of the Tools in order to remove the deprecation warnings. >> >> Magnus' webrev http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01/ does add/duplicate some code, but I like it for keeping things working 8-) > > Here's an updated version of that approach that minimizes the amount of new code: > > http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.03 > > The difference is that I do not duplicate the classes themselves, I just subclass them to get a single point where the @SuppressWarnings can be put. The only change needed in the rest of the files is to make sure we import these classes instead of the ones in java.util. > > /Magnus > >> >> >> Thanks >> Kevin >> >> >> On 31/03/2020 22:20, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 3/31/20 4:55 PM, Chris Plummer wrote: >>>> On 3/31/20 1:32 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 3/31/20 12:19 PM, Poonam Parhar wrote: >>>>>> Hello Coleen, >>>>>> >>>>>> Does the removal of this code only impact the 'reattach' functionality, and it does not affect any commands available in 'clhsdb' once it is attached to a core file? If that's true, then I think it should be okay to remove this code. >>>>> >>>>> Hi Poonam,? Thank you for answering. Yes, this patch only removes the reattach functionality.? I tried out the other clhsdb commands from your wiki page, and they worked fine, including object and heap inspection. >>>> I'm trying to understand exactly when all these static initializes are triggered. Is it only after you do an attach? >>>> >>>> The implementation of clhsdb reattach is exactly the same as doing a detach followed by an attach to the same process. I'm not sure how much value it has, but I think in general the removal of this code means you can't detach and then attach to anything, even a different pid. So "detach" might as well become "detach-and-exit", because your clhsdb session is dead once you detach. Do we really want to do this? >>> >>> Well, that was my question. It seems like you could just exit and start up jhsdb again and that's more like something someone would do just as easily.? Given the use cases that we've seen from sustaining, this appears to be unneeded functionality. >>> >>> The original mail was proposing adding more code to work around the deprecation messages.? It seems like more code should not be added for something that is unused. >>> >>> thanks, >>> Coleen >>> >>>> >>>> Chris >>>>> >>>>> Thanks, >>>>> Coleen >>>>>> >>>>>> Thanks, >>>>>> Poonam >>>>>> >>>>>> On 3/31/20 5:34 AM, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> To answer my own question, this functionality is used to allow detach/reattach from {cl}hsdb.? Which seems to work on linux but not windows with this code removed. >>>>>>> >>>>>>> The next question is whether this is useful functionality to justify all this code (900+ and this new code that Magnus has added).? Can't you just exit and restart the clhsdb process on the core file or process? >>>>>>> >>>>>>> For the record, this is me playing with python to remove this code. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2020/01/webrev/index.html >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 3/30/20 3:04 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> >>>>>>>> I was wondering why this is needed when debugging a core file, which is the key thing we need the SA for: >>>>>>>> >>>>>>>> ? /** This is used by both the debugger and any runtime system. It is >>>>>>>> ????? the basic mechanism by which classes which mimic underlying VM >>>>>>>> ????? functionality cause themselves to be initialized. The given >>>>>>>> ????? observer will be notified (with arguments (null, null)) when the >>>>>>>> ????? VM is re-initialized, as well as when it registers itself with >>>>>>>> ????? the VM. */ >>>>>>>> ? public static void registerVMInitializedObserver(Observer o) { >>>>>>>> ??? vmInitializedObservers.add(o); >>>>>>>> ??? o.update(null, null); >>>>>>>> ? } >>>>>>>> >>>>>>>> It seems like if it isn't needed, we shouldn't add these classes and remove their use. >>>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 3/30/20 8:14 AM, Magnus Ihse Bursie wrote: >>>>>>>>> No opinions on this? >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> On 2020-03-25 23:34, Magnus Ihse Bursie wrote: >>>>>>>>>> Hi everyone, >>>>>>>>>> >>>>>>>>>> As a follow-up to the ongoing review for JDK-8241618, I have also looked at fixing the deprecation warnings in jdk.hotspot.agent. These fall in three broad categories: >>>>>>>>>> >>>>>>>>>> * Deprecation of the boxing type constructors (e.g. "new Integer(42)"). >>>>>>>>>> >>>>>>>>>> * Deprecation of java.util.Observer and Observable. >>>>>>>>>> >>>>>>>>>> * The rest (mostly Class.newInstance(), and a few number of other odd deprecations) >>>>>>>>>> >>>>>>>>>> The first category is trivial to fix. The last category need some special discussion. But the overwhelming majority of deprecation warnings come from the use of Observer and Observable. This really dwarfs anything else, and needs to be handled first, otherwise it's hard to even spot the other issues. >>>>>>>>>> >>>>>>>>>> My analysis of the situation is that the deprecation of Observer and Observable seems a bit harsh, from the PoV of jdk.hotspot.agent. Sure, it might be limited, but I think it does exactly what is needed here. So the migration suggested in Observable (java.beans or java.util.concurrent) seems overkill. If there are genuine threading issues at play here, this assumption might be wrong, and then maybe going the j.u.c. route is correct. >>>>>>>>>> >>>>>>>>>> But if that's not, the main goal should be to stay with the current implementation. One way to do this is to sprinkle the code with @SuppressWarning. But I think a better way would be to just implement our own Observer and Observable. After all, the classes are trivial. >>>>>>>>>> >>>>>>>>>> I've made a mock-up of this solution, were I just copied the java.util.Observer and Observable, and removed the deprecation annotations. The only thing needed for the rest of the code is to make sure we import these; I've done this for three arbitrarily selected classes just to show what the change would typically look like. Here's the mock-up: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ihse/hotspot-agent-observer/webrev.01 >>>>>>>>>> >>>>>>>>>> Let me know what you think. >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> > From mandy.chung at oracle.com Thu Apr 2 18:56:47 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Apr 2020 11:56:47 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: Hi David, Thank you for checking thoroughly.?? I now grep on src/hotspot and clean all of them. Updated delta webrev: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04-delta/ On 4/1/20 11:21 PM, David Holmes wrote: > Hi Mandy, > > On 2/04/2020 3:17 pm, Mandy Chung wrote: >> Hi David, >> >> Thanks for the edits to the comments.?? "weak hidden" were missed to >> be changed to "non-strong hidden".? Here is the patch fixing the >> comments. > > There are 33 cases of "weak hidden" in the patch I reviewed and also > some "hidden weak". Should they all be "non-strong hidden" now? yes, supposed to.?? All should be fixed in webrev.04-delta. > In some cases it also appears in variables and associated logic ie.: > > src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp > > +????? _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), > Are you reading webrev.03???? This has been fixed in webrev.04. I found Klass::is_hidden_weak that should have been renamed too. > I'm not clear how far this terminology change needs to extend ?? > I hope consistently used in the source. > Otherwise patch below seems fine. > Revised the patch. Thanks Mandy > Thanks, > David > ----- > > >> diff --git a/src/hotspot/share/ci/ciField.cpp >> b/src/hotspot/share/ci/ciField.cpp >> --- a/src/hotspot/share/ci/ciField.cpp >> +++ b/src/hotspot/share/ci/ciField.cpp >> @@ -223,8 +223,8 @@ >> ??????? holder->is_in_package("jdk/internal/foreign") || >> holder->is_in_package("jdk/incubator/foreign") || >> ??????? holder->is_in_package("java/lang")) >> ????? return true; >> -? // Trust VM hidden and unsafe anonymous classes. They are created >> via Lookup.defineClass or >> -? // the private API (jdk.internal.misc.Unsafe) and can't be >> serialized, so there is no hacking >> +? // Trust hidden and VM unsafe anonymous classes. They are created >> via Lookup.defineClass or >> +? // the private jdk.internal.misc.Unsafe API and can't be >> serialized, so there is no hacking >> ??? // of finals going on with them. >> ??? if (holder->is_hidden() || holder->is_unsafe_anonymous()) >> ????? return true; >> diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp >> b/src/hotspot/share/ci/ciInstanceKlass.cpp >> --- a/src/hotspot/share/ci/ciInstanceKlass.cpp >> +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp >> @@ -76,7 +76,7 @@ >> ??? oop holder = ik->klass_holder(); >> ??? if (ik->class_loader_data()->has_class_mirror_holder()) { >> ????? // Though ciInstanceKlass records class loader oop, it's not >> enough to keep >> -??? // VM weak hidden and unsafe anonymous classes alive (loader == >> NULL). Klass holder should >> +??? // non-strong hidden class and VM unsafe anonymous classes alive >> (loader == NULL). Klass holder should >> ????? // be used instead. It is enough to record a ciObject, since >> cached elements are never removed >> ????? // during ciObjectFactory lifetime. ciObjectFactory itself is >> created for >> ????? // every compilation and lives for the whole duration of the >> compilation. >> diff --git a/src/hotspot/share/classfile/classLoaderData.hpp >> b/src/hotspot/share/classfile/classLoaderData.hpp >> --- a/src/hotspot/share/classfile/classLoaderData.hpp >> +++ b/src/hotspot/share/classfile/classLoaderData.hpp >> @@ -127,9 +127,10 @@ >> ??? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS >> support) >> >> ??? int _keep_alive;???????? // if this CLD is kept alive. >> -?????????????????????????? // Used for weak hidden classes, unsafe >> anonymous classes and the >> +?????????????????????????? // Used for non-strong hidden classes, >> unsafe anonymous classes and the >> ???????????????????????????? // boot class loader. _keep_alive does >> not need to be volatile or >> -?????????????????????????? // atomic since there is one unique CLD >> per weak hidden or unsafe anonymous class. >> +?????????????????????????? // atomic since there is one unique CLD >> per non-strong hidden class >> +?????????????????????????? // or unsafe anonymous class. >> >> ??? volatile int _claim; // non-zero if claimed, for example during >> GC traces. >> ???????????????????????? // To avoid applying oop closure more than >> once. >> @@ -242,15 +243,15 @@ >> ??? } >> >> ??? // Returns true if this class loader data is for the system class >> loader. >> -? // (Note that the class loader data may be for an weak hidden or >> unsafe anonymous class) >> +? // (Note that the class loader data may be for a non-strong hidden >> class or unsafe anonymous class) >> ??? bool is_system_class_loader_data() const; >> >> ??? // Returns true if this class loader data is for the platform >> class loader. >> -? // (Note that the class loader data may be for an weak hidden or >> unsafe anonymous class) >> +? // (Note that the class loader data may be for a non-strong hidden >> class or unsafe anonymous class) >> ??? bool is_platform_class_loader_data() const; >> >> ??? // Returns true if this class loader data is for the boot class >> loader. >> -? // (Note that the class loader data may be for an weak hidden >> unsafe anonymous class) >> +? // (Note that the class loader data may be for a non-strong hidden >> class or unsafe anonymous class) >> ??? inline bool is_boot_class_loader_data() const; >> >> ??? bool is_builtin_class_loader_data() const; >> @@ -271,7 +272,7 @@ >> ????? return _unloading; >> ??? } >> >> -? // Used to refcount an weak hidden or unsafe anonymous class's CLD >> in order to >> +? // Used to refcount a non-strong hidden class's or unsafe >> anonymous class's CLD in order to >> ??? // indicate their aliveness. >> ??? void inc_keep_alive(); >> ??? void dec_keep_alive(); >> >> diff --git a/src/hotspot/share/interpreter/linkResolver.cpp >> b/src/hotspot/share/interpreter/linkResolver.cpp >> --- a/src/hotspot/share/interpreter/linkResolver.cpp >> +++ b/src/hotspot/share/interpreter/linkResolver.cpp >> @@ -611,7 +611,7 @@ >> ?????????????? (same_module) ? "" : >> sel_klass->class_in_module_of_loader() >> ?????????????? ); >> >> -??? // For private access check if there was a problem with nest host >> +??? // For private access see if there was a problem with nest host >> ????? // resolution, and if so report that as part of the message. >> ????? if (sel_method->is_private()) { >> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >> @@ -951,7 +951,7 @@ >> ?????????????? (same_module) ? "" : "; ", >> ?????????????? (same_module) ? "" : >> sel_klass->class_in_module_of_loader() >> ?????????????? ); >> -??? // For private access check if there was a problem with nest host >> +??? // For private access see if there was a problem with nest host >> ????? // resolution, and if so report that as part of the message. >> ????? if (fd.is_private()) { >> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >> >> Mandy >> >> On 4/1/20 9:52 PM, David Holmes wrote: >>> Hi Mandy, >>> >>> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>>> Thanks to the review feedbacks. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>>> >>> >>> I've had a good look through all the hotspot related changes. All >>> looks good. >>> >>> A few minor comments: >>> >>> src/hotspot/share/ci/ciField.cpp >>> >>> ?? // Trust VM hidden and unsafe anonymous classes. >>> >>> should say >>> >>> ?? // Trust hidden and VM unsafe anonymous classes. >>> >>> >>> ? // the private API (jdk.internal.misc.Unsafe) >>> >>> s/the/a/? or else change the () to commas or perhaps even better: >>> >>> ? // the private jdk.internal.misc.Unsafe API, >>> >>> --- >>> >>> src/hotspot/share/ci/ciInstanceKlass.cpp >>> >>> ? // VM weak hidden and unsafe anonymous classes >>> >>> should say >>> >>> ? // weak hidden and VM unsafe anonymous classes >>> >>> --- >>> >>> src/hotspot/share/classfile/classLoaderData.hpp >>> >>> !? // the CLDs lifecycle.? For example, a non-strong hidden class or an >>> ... >>> !? // Used for weak hidden classes, unsafe anonymous classes and the >>> >>> There is an inconsistency in terminology, so far most code comments >>> refer to "weak hidden" but now you are using "non-strong hidden". >>> >>> ! for an weak hidden >>> >>> s/an/a/?? multiple locations >>> >>> --- >>> >>> src/hotspot/share/interpreter/linkResolver.cpp >>> >>> Can you fix one of my comments please (in two places) :) >>> >>> +???? // For private access check if there was a problem with nest host >>> >>> would read better as: >>> >>> +???? // For private access see if there was a problem with nest host >>> >>> --- >>> >>> Thanks, >>> David >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Thu Apr 2 19:51:45 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 2 Apr 2020 12:51:45 -0700 Subject: RFR: 8241456: ThreadRunner shouldn't use Wicket for threads starting synchronization In-Reply-To: References: <412d8c29-7742-a138-dc74-8f07def5eeae@oracle.com> <9502df2b-07d1-b1d2-5e66-fce0eb4ac9d7@oracle.com> <12701240-fd7d-560d-8974-ff0be9cafa7e@oracle.com> <70175e02-2c50-50e7-0646-4fb82be6c768@oracle.com> <01083dfc-1a73-4f47-c340-a734868c9e51@oracle.com> Message-ID: <8c0348d2-72f6-3dc4-af1e-1825ec3a2ebe@oracle.com> Thank you for review. I still waiting for one more review. Leonid On 4/1/20 9:18 PM, David Holmes wrote: > Looks good - thanks Leonid. > > David > > On 2/04/2020 12:17 pm, Leonid Mesnik wrote: >> Find new version (updated webrev.00 by mistake) >> >> http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00/ >> >> The moving lock.lock() outside of try is required to don't get >> IllegalStateException. >> >> And avoiding locks in ThreadRunner is needed to avoid OOME. >> >> Leonid >> >> On 3/26/20 4:41 PM, Leonid Mesnik wrote: >>> >>> On 3/26/20 4:29 PM, David Holmes wrote: >>>> On 27/03/2020 9:16 am, Leonid Mesnik wrote: >>>>> >>>>> On 3/26/20 4:06 PM, David Holmes wrote: >>>>>> Hi Leonid, >>>>>> >>>>>> On 27/03/2020 7:39 am, Leonid Mesnik wrote: >>>>>>> Replying with correct summary. >>>>>>> >>>>>>> Leonid >>>>>>> >>>>>>> On 3/23/20 8:55 PM, Leonid Mesnik wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> Could you please review following fix which update >>>>>>>> ThreadsRunner to use AtomicInteger/spinOnWait instead of Wicket >>>>>>>> to synchronize starting of stress test threads. >>>>>>>> >>>>>>>> Failing tests allocated all memory by earlier started threads >>>>>>>> before Lock.unlock is called in the latest threads. So thread >>>>>>>> might get an OOME exception while trying to release lock and/or >>>>>>>> get into inconsistent state. >>>>>> >>>>>> You have a bug in Wicket: >>>>>> >>>>>> +??????? try { >>>>>> +??????????? lock.lock(); >>>>>> ... >>>>>> +??????? } finally { >>>>>> +??????????? lock.unlock(); >>>>>> >>>>>> The lock() has to go outside the try block. That is why you were >>>>>> getting IllegalMonitorStateExceptions when the lock() threw OOME. >>>>> Thanks for explanation. But anyway, as I understand locks use >>>>> memory and might be inconsistent if OOME happened. >>>> >>>> They use memory and so lock() can throw OOME, but they are never >>>> inconsistent. >>> Ok, I will move lock.lock() outside of try {}. Thanks for explanation. >>>> >>>>>> >>>>>> But the OOME itself is still a problem as it means you can't use >>>>>> any proper synchronizer. I don't like seeing the spin-loops but >>>>>> in this code you may have no choice if memory may already be >>>>>> exhausted. >>>>> >>>>> It should be really short spin-loop, test only start thread during >>>>> this loop and don't do anything more. Also, it is done only once >>>>> for all stress test. The goal is to start thread completely before >>>>> heap is exhausted. >>>> >>>> Okay. I'm somewhat dubious about making these changes in mainline >>>> now just to support loom. I don't see why we need to care about >>>> pinning threads in this kind of situation. >>> >>> The idea is to add some nsk/share stress tests for virtual threads. >>> Basically, there are the same tests as existing (gc, sysdict) but >>> running in virtual threads. And these tests are going to be executed >>> after loom is integrated. And I want to keep the difference as small >>> as possible between mainline and loom. >>> >>> Leonid >>> >>>> >>>> David >>>> >>>>> Leonid >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>>> >>>>>>>> The bug was introduced by >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8241123 >>>>>>>> >>>>>>>> The Atomic works fine for stress test finishing sync. I just >>>>>>>> didn't expect that tests might OOME while releasing start lock. >>>>>>>> Verified that tests now don't fail with -Xcomp -server >>>>>>>> -XX:-TieredCompilation -XX:-UseCompressedOops. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00/ >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8241456 >>>>>>>> >>>>>>>> >>>>>>>> Leonid From igor.ignatyev at oracle.com Thu Apr 2 19:56:33 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 2 Apr 2020 12:56:33 -0700 Subject: RFR: 8241456: ThreadRunner shouldn't use Wicket for threads starting synchronization In-Reply-To: <8c0348d2-72f6-3dc4-af1e-1825ec3a2ebe@oracle.com> References: <412d8c29-7742-a138-dc74-8f07def5eeae@oracle.com> <9502df2b-07d1-b1d2-5e66-fce0eb4ac9d7@oracle.com> <12701240-fd7d-560d-8974-ff0be9cafa7e@oracle.com> <70175e02-2c50-50e7-0646-4fb82be6c768@oracle.com> <01083dfc-1a73-4f47-c340-a734868c9e51@oracle.com> <8c0348d2-72f6-3dc4-af1e-1825ec3a2ebe@oracle.com> Message-ID: LGTM -- Igor > On Apr 2, 2020, at 12:51 PM, Leonid Mesnik wrote: > > Thank you for review. > > I still waiting for one more review. > > Leonid > > On 4/1/20 9:18 PM, David Holmes wrote: >> Looks good - thanks Leonid. >> >> David >> >> On 2/04/2020 12:17 pm, Leonid Mesnik wrote: >>> Find new version (updated webrev.00 by mistake) >>> >>> http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00/ >>> >>> The moving lock.lock() outside of try is required to don't get IllegalStateException. >>> >>> And avoiding locks in ThreadRunner is needed to avoid OOME. >>> >>> Leonid >>> >>> On 3/26/20 4:41 PM, Leonid Mesnik wrote: >>>> >>>> On 3/26/20 4:29 PM, David Holmes wrote: >>>>> On 27/03/2020 9:16 am, Leonid Mesnik wrote: >>>>>> >>>>>> On 3/26/20 4:06 PM, David Holmes wrote: >>>>>>> Hi Leonid, >>>>>>> >>>>>>> On 27/03/2020 7:39 am, Leonid Mesnik wrote: >>>>>>>> Replying with correct summary. >>>>>>>> >>>>>>>> Leonid >>>>>>>> >>>>>>>> On 3/23/20 8:55 PM, Leonid Mesnik wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Could you please review following fix which update ThreadsRunner to use AtomicInteger/spinOnWait instead of Wicket to synchronize starting of stress test threads. >>>>>>>>> >>>>>>>>> Failing tests allocated all memory by earlier started threads before Lock.unlock is called in the latest threads. So thread might get an OOME exception while trying to release lock and/or get into inconsistent state. >>>>>>> >>>>>>> You have a bug in Wicket: >>>>>>> >>>>>>> + try { >>>>>>> + lock.lock(); >>>>>>> ... >>>>>>> + } finally { >>>>>>> + lock.unlock(); >>>>>>> >>>>>>> The lock() has to go outside the try block. That is why you were getting IllegalMonitorStateExceptions when the lock() threw OOME. >>>>>> Thanks for explanation. But anyway, as I understand locks use memory and might be inconsistent if OOME happened. >>>>> >>>>> They use memory and so lock() can throw OOME, but they are never inconsistent. >>>> Ok, I will move lock.lock() outside of try {}. Thanks for explanation. >>>>> >>>>>>> >>>>>>> But the OOME itself is still a problem as it means you can't use any proper synchronizer. I don't like seeing the spin-loops but in this code you may have no choice if memory may already be exhausted. >>>>>> >>>>>> It should be really short spin-loop, test only start thread during this loop and don't do anything more. Also, it is done only once for all stress test. The goal is to start thread completely before heap is exhausted. >>>>> >>>>> Okay. I'm somewhat dubious about making these changes in mainline now just to support loom. I don't see why we need to care about pinning threads in this kind of situation. >>>> >>>> The idea is to add some nsk/share stress tests for virtual threads. Basically, there are the same tests as existing (gc, sysdict) but running in virtual threads. And these tests are going to be executed after loom is integrated. And I want to keep the difference as small as possible between mainline and loom. >>>> >>>> Leonid >>>> >>>>> >>>>> David >>>>> >>>>>> Leonid >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> The bug was introduced by https://bugs.openjdk.java.net/browse/JDK-8241123 >>>>>>>>> The Atomic works fine for stress test finishing sync. I just didn't expect that tests might OOME while releasing start lock. >>>>>>>>> Verified that tests now don't fail with -Xcomp -server -XX:-TieredCompilation -XX:-UseCompressedOops. >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00/ >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8241456 >>>>>>>>> >>>>>>>>> Leonid From lois.foltan at oracle.com Thu Apr 2 20:28:07 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 2 Apr 2020 16:28:07 -0400 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: <333b05fb-65c6-e8ef-a804-b624c2da56c5@oracle.com> On 4/2/2020 2:56 PM, Mandy Chung wrote: > Hi David, > > Thank you for checking thoroughly.?? I now grep on src/hotspot and > clean all of them. > > Updated delta webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04-delta/ > Patch looks good Mandy. Lois > > On 4/1/20 11:21 PM, David Holmes wrote: >> Hi Mandy, >> >> On 2/04/2020 3:17 pm, Mandy Chung wrote: >>> Hi David, >>> >>> Thanks for the edits to the comments.?? "weak hidden" were missed to >>> be changed to "non-strong hidden".? Here is the patch fixing the >>> comments. >> >> There are 33 cases of "weak hidden" in the patch I reviewed and also >> some "hidden weak". Should they all be "non-strong hidden" now? > > yes, supposed to.?? All should be fixed in webrev.04-delta. > >> In some cases it also appears in variables and associated logic ie.: >> >> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp >> >> +????? _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), >> > > Are you reading webrev.03???? This has been fixed in webrev.04. > > I found Klass::is_hidden_weak that should have been renamed too. > >> I'm not clear how far this terminology change needs to extend ?? >> > > I hope consistently used in the source. > >> Otherwise patch below seems fine. >> > > Revised the patch. > > Thanks > Mandy >> Thanks, >> David >> ----- >> >> >>> diff --git a/src/hotspot/share/ci/ciField.cpp >>> b/src/hotspot/share/ci/ciField.cpp >>> --- a/src/hotspot/share/ci/ciField.cpp >>> +++ b/src/hotspot/share/ci/ciField.cpp >>> @@ -223,8 +223,8 @@ >>> ??????? holder->is_in_package("jdk/internal/foreign") || >>> holder->is_in_package("jdk/incubator/foreign") || >>> ??????? holder->is_in_package("java/lang")) >>> ????? return true; >>> -? // Trust VM hidden and unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> -? // the private API (jdk.internal.misc.Unsafe) and can't be >>> serialized, so there is no hacking >>> +? // Trust hidden and VM unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> +? // the private jdk.internal.misc.Unsafe API and can't be >>> serialized, so there is no hacking >>> ??? // of finals going on with them. >>> ??? if (holder->is_hidden() || holder->is_unsafe_anonymous()) >>> ????? return true; >>> diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> --- a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> @@ -76,7 +76,7 @@ >>> ??? oop holder = ik->klass_holder(); >>> ??? if (ik->class_loader_data()->has_class_mirror_holder()) { >>> ????? // Though ciInstanceKlass records class loader oop, it's not >>> enough to keep >>> -??? // VM weak hidden and unsafe anonymous classes alive (loader == >>> NULL). Klass holder should >>> +??? // non-strong hidden class and VM unsafe anonymous classes >>> alive (loader == NULL). Klass holder should >>> ????? // be used instead. It is enough to record a ciObject, since >>> cached elements are never removed >>> ????? // during ciObjectFactory lifetime. ciObjectFactory itself is >>> created for >>> ????? // every compilation and lives for the whole duration of the >>> compilation. >>> diff --git a/src/hotspot/share/classfile/classLoaderData.hpp >>> b/src/hotspot/share/classfile/classLoaderData.hpp >>> --- a/src/hotspot/share/classfile/classLoaderData.hpp >>> +++ b/src/hotspot/share/classfile/classLoaderData.hpp >>> @@ -127,9 +127,10 @@ >>> ??? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS >>> support) >>> >>> ??? int _keep_alive;???????? // if this CLD is kept alive. >>> -?????????????????????????? // Used for weak hidden classes, unsafe >>> anonymous classes and the >>> +?????????????????????????? // Used for non-strong hidden classes, >>> unsafe anonymous classes and the >>> ???????????????????????????? // boot class loader. _keep_alive does >>> not need to be volatile or >>> -?????????????????????????? // atomic since there is one unique CLD >>> per weak hidden or unsafe anonymous class. >>> +?????????????????????????? // atomic since there is one unique CLD >>> per non-strong hidden class >>> +?????????????????????????? // or unsafe anonymous class. >>> >>> ??? volatile int _claim; // non-zero if claimed, for example during >>> GC traces. >>> ???????????????????????? // To avoid applying oop closure more than >>> once. >>> @@ -242,15 +243,15 @@ >>> ??? } >>> >>> ??? // Returns true if this class loader data is for the system >>> class loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong >>> hidden class or unsafe anonymous class) >>> ??? bool is_system_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the platform >>> class loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong >>> hidden class or unsafe anonymous class) >>> ??? bool is_platform_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the boot class >>> loader. >>> -? // (Note that the class loader data may be for an weak hidden >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong >>> hidden class or unsafe anonymous class) >>> ??? inline bool is_boot_class_loader_data() const; >>> >>> ??? bool is_builtin_class_loader_data() const; >>> @@ -271,7 +272,7 @@ >>> ????? return _unloading; >>> ??? } >>> >>> -? // Used to refcount an weak hidden or unsafe anonymous class's >>> CLD in order to >>> +? // Used to refcount a non-strong hidden class's or unsafe >>> anonymous class's CLD in order to >>> ??? // indicate their aliveness. >>> ??? void inc_keep_alive(); >>> ??? void dec_keep_alive(); >>> >>> diff --git a/src/hotspot/share/interpreter/linkResolver.cpp >>> b/src/hotspot/share/interpreter/linkResolver.cpp >>> --- a/src/hotspot/share/interpreter/linkResolver.cpp >>> +++ b/src/hotspot/share/interpreter/linkResolver.cpp >>> @@ -611,7 +611,7 @@ >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (sel_method->is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> @@ -951,7 +951,7 @@ >>> ?????????????? (same_module) ? "" : "; ", >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (fd.is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> >>> Mandy >>> >>> On 4/1/20 9:52 PM, David Holmes wrote: >>>> Hi Mandy, >>>> >>>> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>>>> Thanks to the review feedbacks. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>>>> >>>> >>>> I've had a good look through all the hotspot related changes. All >>>> looks good. >>>> >>>> A few minor comments: >>>> >>>> src/hotspot/share/ci/ciField.cpp >>>> >>>> ?? // Trust VM hidden and unsafe anonymous classes. >>>> >>>> should say >>>> >>>> ?? // Trust hidden and VM unsafe anonymous classes. >>>> >>>> >>>> ? // the private API (jdk.internal.misc.Unsafe) >>>> >>>> s/the/a/? or else change the () to commas or perhaps even better: >>>> >>>> ? // the private jdk.internal.misc.Unsafe API, >>>> >>>> --- >>>> >>>> src/hotspot/share/ci/ciInstanceKlass.cpp >>>> >>>> ? // VM weak hidden and unsafe anonymous classes >>>> >>>> should say >>>> >>>> ? // weak hidden and VM unsafe anonymous classes >>>> >>>> --- >>>> >>>> src/hotspot/share/classfile/classLoaderData.hpp >>>> >>>> !? // the CLDs lifecycle.? For example, a non-strong hidden class >>>> or an >>>> ... >>>> !? // Used for weak hidden classes, unsafe anonymous classes and the >>>> >>>> There is an inconsistency in terminology, so far most code comments >>>> refer to "weak hidden" but now you are using "non-strong hidden". >>>> >>>> ! for an weak hidden >>>> >>>> s/an/a/?? multiple locations >>>> >>>> --- >>>> >>>> src/hotspot/share/interpreter/linkResolver.cpp >>>> >>>> Can you fix one of my comments please (in two places) :) >>>> >>>> +???? // For private access check if there was a problem with nest >>>> host >>>> >>>> would read better as: >>>> >>>> +???? // For private access see if there was a problem with nest host >>>> >>>> --- >>>> >>>> Thanks, >>>> David >>>> >>> > From chris.plummer at oracle.com Thu Apr 2 20:46:17 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 2 Apr 2020 13:46:17 -0700 Subject: RFR(S) 8240989: convert clhsdb "dumpheap" command from javascript to java Message-ID: <2471b2e2-d3f9-a771-6a7b-f644c1efd241@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8240989 http://cr.openjdk.java.net/~cjplummer/8240989/webrev.01/ See the CR for details. For the test I used ClhsdbField.java as a simple clhsdb template. To verify the dumped heap I added the call to printStackTraces(), which came from test/jdk/sun/tools/jhsdb/HeapDumpTest.java. thanks, Chris From alexey.menkov at oracle.com Thu Apr 2 23:20:18 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 2 Apr 2020 16:20:18 -0700 Subject: RFR: JDK-8237572: Combine the two LingeredApp classes Message-ID: <3ba8b09b-2570-86cb-6fc5-65e41947c77d@oracle.com> Hi all, please review the fix for https://bugs.openjdk.java.net/browse/JDK-8237572 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/jpsLingeredApp/webrev/ verified all test which use LangeredApp pass. --alex From suenaga at oss.nttdata.com Fri Apr 3 00:17:52 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 3 Apr 2020 09:17:52 +0900 Subject: RFR(S) 8240989: convert clhsdb "dumpheap" command from javascript to java In-Reply-To: <2471b2e2-d3f9-a771-6a7b-f644c1efd241@oracle.com> References: <2471b2e2-d3f9-a771-6a7b-f644c1efd241@oracle.com> Message-ID: <03da99ea-6369-392a-5990-17eeaa16c40d@oss.nttdata.com> Hi Chris, Looks good! Yasumasa On 2020/04/03 5:46, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8240989 > http://cr.openjdk.java.net/~cjplummer/8240989/webrev.01/ > > See the CR for details. > > For the test I used ClhsdbField.java as a simple clhsdb template. To verify the dumped heap I added the call to printStackTraces(), which came from test/jdk/sun/tools/jhsdb/HeapDumpTest.java. > > thanks, > > Chris From alexey.menkov at oracle.com Fri Apr 3 00:35:13 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 2 Apr 2020 17:35:13 -0700 Subject: RFR(S) 8240989: convert clhsdb "dumpheap" command from javascript to java In-Reply-To: <03da99ea-6369-392a-5990-17eeaa16c40d@oss.nttdata.com> References: <2471b2e2-d3f9-a771-6a7b-f644c1efd241@oracle.com> <03da99ea-6369-392a-5990-17eeaa16c40d@oss.nttdata.com> Message-ID: <6ff111c0-5eec-7462-e546-1fc40e262e58@oracle.com> +1 --alex On 04/02/2020 17:17, Yasumasa Suenaga wrote: > Hi Chris, > > Looks good! > > > Yasumasa > > > On 2020/04/03 5:46, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8240989 >> http://cr.openjdk.java.net/~cjplummer/8240989/webrev.01/ >> >> See the CR for details. >> >> For the test I used ClhsdbField.java as a simple clhsdb template. To >> verify the dumped heap I added the call to printStackTraces(), which >> came from test/jdk/sun/tools/jhsdb/HeapDumpTest.java. >> >> thanks, >> >> Chris From david.holmes at oracle.com Fri Apr 3 01:36:03 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Apr 2020 11:36:03 +1000 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <319b5917-397f-5ac1-9c94-56f558653797@oracle.com> Message-ID: <10e51a8a-6d69-db08-d4f9-f578ec591ee2@oracle.com> Hi Mandy, Update seems fine. Thanks, David On 3/04/2020 4:56 am, Mandy Chung wrote: > Hi David, > > Thank you for checking thoroughly.?? I now grep on src/hotspot and clean > all of them. > > Updated delta webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04-delta/ > > On 4/1/20 11:21 PM, David Holmes wrote: >> Hi Mandy, >> >> On 2/04/2020 3:17 pm, Mandy Chung wrote: >>> Hi David, >>> >>> Thanks for the edits to the comments.?? "weak hidden" were missed to >>> be changed to "non-strong hidden".? Here is the patch fixing the >>> comments. >> >> There are 33 cases of "weak hidden" in the patch I reviewed and also >> some "hidden weak". Should they all be "non-strong hidden" now? > > yes, supposed to.?? All should be fixed in webrev.04-delta. > >> In some cases it also appears in variables and associated logic ie.: >> >> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp >> >> +????? _hidden_weak_classes(NULL), _num_hidden_weak_classes(0), >> > > Are you reading webrev.03???? This has been fixed in webrev.04. > > I found Klass::is_hidden_weak that should have been renamed too. > >> I'm not clear how far this terminology change needs to extend ?? >> > > I hope consistently used in the source. > >> Otherwise patch below seems fine. >> > > Revised the patch. > > Thanks > Mandy >> Thanks, >> David >> ----- >> >> >>> diff --git a/src/hotspot/share/ci/ciField.cpp >>> b/src/hotspot/share/ci/ciField.cpp >>> --- a/src/hotspot/share/ci/ciField.cpp >>> +++ b/src/hotspot/share/ci/ciField.cpp >>> @@ -223,8 +223,8 @@ >>> ??????? holder->is_in_package("jdk/internal/foreign") || >>> holder->is_in_package("jdk/incubator/foreign") || >>> ??????? holder->is_in_package("java/lang")) >>> ????? return true; >>> -? // Trust VM hidden and unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> -? // the private API (jdk.internal.misc.Unsafe) and can't be >>> serialized, so there is no hacking >>> +? // Trust hidden and VM unsafe anonymous classes. They are created >>> via Lookup.defineClass or >>> +? // the private jdk.internal.misc.Unsafe API and can't be >>> serialized, so there is no hacking >>> ??? // of finals going on with them. >>> ??? if (holder->is_hidden() || holder->is_unsafe_anonymous()) >>> ????? return true; >>> diff --git a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> --- a/src/hotspot/share/ci/ciInstanceKlass.cpp >>> +++ b/src/hotspot/share/ci/ciInstanceKlass.cpp >>> @@ -76,7 +76,7 @@ >>> ??? oop holder = ik->klass_holder(); >>> ??? if (ik->class_loader_data()->has_class_mirror_holder()) { >>> ????? // Though ciInstanceKlass records class loader oop, it's not >>> enough to keep >>> -??? // VM weak hidden and unsafe anonymous classes alive (loader == >>> NULL). Klass holder should >>> +??? // non-strong hidden class and VM unsafe anonymous classes alive >>> (loader == NULL). Klass holder should >>> ????? // be used instead. It is enough to record a ciObject, since >>> cached elements are never removed >>> ????? // during ciObjectFactory lifetime. ciObjectFactory itself is >>> created for >>> ????? // every compilation and lives for the whole duration of the >>> compilation. >>> diff --git a/src/hotspot/share/classfile/classLoaderData.hpp >>> b/src/hotspot/share/classfile/classLoaderData.hpp >>> --- a/src/hotspot/share/classfile/classLoaderData.hpp >>> +++ b/src/hotspot/share/classfile/classLoaderData.hpp >>> @@ -127,9 +127,10 @@ >>> ??? bool _accumulated_modified_oops; // Mod Union Equivalent (CMS >>> support) >>> >>> ??? int _keep_alive;???????? // if this CLD is kept alive. >>> -?????????????????????????? // Used for weak hidden classes, unsafe >>> anonymous classes and the >>> +?????????????????????????? // Used for non-strong hidden classes, >>> unsafe anonymous classes and the >>> ???????????????????????????? // boot class loader. _keep_alive does >>> not need to be volatile or >>> -?????????????????????????? // atomic since there is one unique CLD >>> per weak hidden or unsafe anonymous class. >>> +?????????????????????????? // atomic since there is one unique CLD >>> per non-strong hidden class >>> +?????????????????????????? // or unsafe anonymous class. >>> >>> ??? volatile int _claim; // non-zero if claimed, for example during >>> GC traces. >>> ???????????????????????? // To avoid applying oop closure more than >>> once. >>> @@ -242,15 +243,15 @@ >>> ??? } >>> >>> ??? // Returns true if this class loader data is for the system class >>> loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong hidden >>> class or unsafe anonymous class) >>> ??? bool is_system_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the platform >>> class loader. >>> -? // (Note that the class loader data may be for an weak hidden or >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong hidden >>> class or unsafe anonymous class) >>> ??? bool is_platform_class_loader_data() const; >>> >>> ??? // Returns true if this class loader data is for the boot class >>> loader. >>> -? // (Note that the class loader data may be for an weak hidden >>> unsafe anonymous class) >>> +? // (Note that the class loader data may be for a non-strong hidden >>> class or unsafe anonymous class) >>> ??? inline bool is_boot_class_loader_data() const; >>> >>> ??? bool is_builtin_class_loader_data() const; >>> @@ -271,7 +272,7 @@ >>> ????? return _unloading; >>> ??? } >>> >>> -? // Used to refcount an weak hidden or unsafe anonymous class's CLD >>> in order to >>> +? // Used to refcount a non-strong hidden class's or unsafe >>> anonymous class's CLD in order to >>> ??? // indicate their aliveness. >>> ??? void inc_keep_alive(); >>> ??? void dec_keep_alive(); >>> >>> diff --git a/src/hotspot/share/interpreter/linkResolver.cpp >>> b/src/hotspot/share/interpreter/linkResolver.cpp >>> --- a/src/hotspot/share/interpreter/linkResolver.cpp >>> +++ b/src/hotspot/share/interpreter/linkResolver.cpp >>> @@ -611,7 +611,7 @@ >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (sel_method->is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> @@ -951,7 +951,7 @@ >>> ?????????????? (same_module) ? "" : "; ", >>> ?????????????? (same_module) ? "" : >>> sel_klass->class_in_module_of_loader() >>> ?????????????? ); >>> -??? // For private access check if there was a problem with nest host >>> +??? // For private access see if there was a problem with nest host >>> ????? // resolution, and if so report that as part of the message. >>> ????? if (fd.is_private()) { >>> ??????? print_nest_host_error_on(&ss, ref_klass, sel_klass, THREAD); >>> >>> Mandy >>> >>> On 4/1/20 9:52 PM, David Holmes wrote: >>>> Hi Mandy, >>>> >>>> On 1/04/2020 1:01 pm, Mandy Chung wrote: >>>>> Thanks to the review feedbacks. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>>>> >>>> >>>> I've had a good look through all the hotspot related changes. All >>>> looks good. >>>> >>>> A few minor comments: >>>> >>>> src/hotspot/share/ci/ciField.cpp >>>> >>>> ?? // Trust VM hidden and unsafe anonymous classes. >>>> >>>> should say >>>> >>>> ?? // Trust hidden and VM unsafe anonymous classes. >>>> >>>> >>>> ? // the private API (jdk.internal.misc.Unsafe) >>>> >>>> s/the/a/? or else change the () to commas or perhaps even better: >>>> >>>> ? // the private jdk.internal.misc.Unsafe API, >>>> >>>> --- >>>> >>>> src/hotspot/share/ci/ciInstanceKlass.cpp >>>> >>>> ? // VM weak hidden and unsafe anonymous classes >>>> >>>> should say >>>> >>>> ? // weak hidden and VM unsafe anonymous classes >>>> >>>> --- >>>> >>>> src/hotspot/share/classfile/classLoaderData.hpp >>>> >>>> !? // the CLDs lifecycle.? For example, a non-strong hidden class or an >>>> ... >>>> !? // Used for weak hidden classes, unsafe anonymous classes and the >>>> >>>> There is an inconsistency in terminology, so far most code comments >>>> refer to "weak hidden" but now you are using "non-strong hidden". >>>> >>>> ! for an weak hidden >>>> >>>> s/an/a/?? multiple locations >>>> >>>> --- >>>> >>>> src/hotspot/share/interpreter/linkResolver.cpp >>>> >>>> Can you fix one of my comments please (in two places) :) >>>> >>>> +???? // For private access check if there was a problem with nest host >>>> >>>> would read better as: >>>> >>>> +???? // For private access see if there was a problem with nest host >>>> >>>> --- >>>> >>>> Thanks, >>>> David >>>> >>> > From peter.levart at gmail.com Fri Apr 3 09:11:04 2020 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 3 Apr 2020 11:11:04 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: Hi Mandy, Good work. I'm trying to find out which language use-case is covered by the InnerClassLambdaMetafactory needing to inject method handle into the generated proxy class to be invoked instead of proxy class directly invoking the method: ??????? useImplMethodHandle = !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) ??????????????????????????????? && !Modifier.isPublic(implInfo.getModifiers()); If I check what implClass and implInfo get resolved to in AbstractValidatingLambdaMetafactory, there are several cases: ??????? this.implInfo = caller.revealDirect(implMethod); ??????? switch (implInfo.getReferenceKind()) { ??????????? case REF_invokeVirtual: ??????????? case REF_invokeInterface: ??????????????? this.implClass = implMethodType.parameterType(0); ??????????????? // reference kind reported by implInfo may not match implMethodType's first param ??????????????? // Example: implMethodType is (Cloneable)String, implInfo is for Object.toString ??????????????? this.implKind = implClass.isInterface() ? REF_invokeInterface : REF_invokeVirtual; ??????????????? this.implIsInstanceMethod = true; ??????????????? break; ??????????? case REF_invokeSpecial: ??????????????? // JDK-8172817: should use referenced class here, but we don't know what it was ??????????????? this.implClass = implInfo.getDeclaringClass(); ??????????????? this.implIsInstanceMethod = true; ??????????????? // Classes compiled prior to dynamic nestmate support invokes a private instance ??????????????? // method with REF_invokeSpecial. ??????????????? // ??????????????? // invokespecial should only be used to invoke private nestmate constructors. ??????????????? // The lambda proxy class will be defined as a nestmate of targetClass. ??????????????? // If the method to be invoked is an instance method of targetClass, then ??????????????? // convert to use invokevirtual or invokeinterface. ??????????????? if (targetClass == implClass && !implInfo.getName().equals("")) { ??????????????????? this.implKind = implClass.isInterface() ? REF_invokeInterface : REF_invokeVirtual; ??????????????? } else { ??????????????????? this.implKind = REF_invokeSpecial; ??????????????? } ??????????????? break; ??????????? case REF_invokeStatic: ??????????? case REF_newInvokeSpecial: ??????????????? // JDK-8172817: should use referenced class here for invokestatic, but we don't know what it was ??????????????? this.implClass = implInfo.getDeclaringClass(); ??????????????? this.implKind = implInfo.getReferenceKind(); ??????????????? this.implIsInstanceMethod = false; ??????????????? break; ??????????? default: ??????????????? throw new LambdaConversionException(String.format("Unsupported MethodHandle kind: %s", implInfo)); ??????? } For majority of cases (REF_invokeSpecial, REF_invokeStatic, REF_newInvokeSpecial) the this.implClass = implInfo.getDeclaringClass(); Only REF_invokeVirtual and REF_invokeInterface are possible kandidates, right? So when does the implMethod type of parameter 0 differ from the declaring class of the MethodHandleInfo cracked from that same implMethod and in addition those two types leave in different packages? Regards, Peter On 3/27/20 12:57 AM, Mandy Chung wrote: > Please review the implementation of JEP 371: Hidden Classes. The main > changes are in core-libs and hotspot runtime area.? Small changes are > made in javac, VM compiler (intrinsification of Class::isHiddenClass), > JFR, JDI, and jcmd.? CSR [1]has been reviewed and is in the finalized > state (see specdiff and javadoc below for reference). > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 > > > Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point > of view, a hidden class is a normal class except the following: > > - A hidden class has no initiating class loader and is not registered > in any dictionary. > - A hidden class has a name containing an illegal character > `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` > returns "Lp/Foo.0x1234;". > - A hidden class is not modifiable, i.e. cannot be redefined or > retransformed. JVM TI IsModifableClass returns false on a hidden. > - Final fields in a hidden class is "final".? The value of final > fields cannot be overriden via reflection.? setAccessible(true) can > still be called on reflected objects representing final fields in a > hidden class and its access check will be suppressed but only have > read-access (i.e. can do Field::getXXX but not setXXX). > > Brief summary of this patch: > > 1. A new Lookup::defineHiddenClass method is the API to create a > hidden class. > 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG > option that > ?? can be specified when creating a hidden class. > 3. A new Class::isHiddenClass method tests if a class is a hidden class. > 4. Field::setXXX method will throw IAE on a final field of a hidden class > ?? regardless of the value of the accessible flag. > 5. JVM_LookupDefineClass is the new JVM entry point for > Lookup::defineClass > ?? and defineHiddenClass to create a class from the given bytes. > 6. ClassLoaderData implementation is not changed.? There is one > primary CLD > ?? that holds the classes strongly referenced by its defining loader.? > There > ?? can be zero or more additional CLDs - one per weak class. > 7. Nest host determination is updated per revised JVMS 5.4.4. Access > control > ?? check no longer throws LinkageError but instead it will throw IAE with > ?? a clear message if a class fails to resolve/validate the nest host > declared > ?? in NestHost/NestMembers attribute. > 8. JFR, jcmd, JDI are updated to support hidden classes. > 9. update javac LambdaToMethod as lambda proxy starts using nestmates > ?? and generate a bridge method to desuger a method reference to a > protected > ?? method in its supertype in a different package > > This patch also updates StringConcatFactory, LambdaMetaFactory, and > LambdaForms > to use hidden classes.? The webrev includes changes in nashorn to > hidden class > and I will update the webrev if JEP 372 removes it any time soon. > > We uncovered a bug in Lookup::defineClass spec throws LinkageError and > intends > to have the newly created class linked.? However, the implementation > in 14 > does not link the class.? A separate CSR [2] proposes to update the > implementation to match the spec.? This patch fixes the implementation. > > The spec update on JVM TI, JDI and Instrumentation will be done as > a separate RFE [3].? This patch includes new tests for JVM TI and > java.instrument that validates how the existing APIs work for hidden > classes. > > javadoc/specdiff > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ > > > JVMS 5.4.4 change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf > > > CSR: > https://bugs.openjdk.java.net/browse/JDK-8238359 > > Thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8238359 > [2] https://bugs.openjdk.java.net/browse/JDK-8240338 > [3] https://bugs.openjdk.java.net/browse/JDK-8230502 From egor.ushakov at jetbrains.com Fri Apr 3 09:16:53 2020 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Fri, 3 Apr 2020 12:16:53 +0300 Subject: RFR: 8241958: Slow ClassLoaderReferenceImpl.findType Message-ID: Hi all, please review the fix The com.sun.tools.jdi.ClassLoaderReferenceImpl#findType may be slow because ClassLoaderReferenceImpl#visibleClasses does not populate signature and we check it for every class in the loop just after, so requesting all unavailable signatures one by one. The fix adds extra check in classesBySignature before comparing signatures of all visible classes. bugid https://bugs.openjdk.java.net/browse/JDK-8241958 cr http://cr.openjdk.java.net/~eushakov/8241958/webrev.00/ Thanks! -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop From peter.levart at gmail.com Fri Apr 3 11:40:54 2020 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 3 Apr 2020 13:40:54 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> Ok, I think I found one such use-case. In the following example: package test; public class LambdaTest { ??? protected void m() { ??? } } package test.sub; public class LambdaTestSub extends test.LambdaTest { ??? public void test() { ??????? Runnable r = this::m; ??????? r.run(); ??? } } ...when compiled with JDK 14 javac. In this case the implClass is test.sub.LambdaTestSub while implInfo is "invokeVirtual test.LambdaTest.m:()void" and the method is not public. Anyway, the name of the proxy class is derived from the targetClass (and therefore shares the same package with targetClass) which is caller's lookup class. Is targetClass always the same as implClass in the invokeVirtual/invokeInterface case? I also noticed that JDK 15 patched javac transforms method reference in above code into a lambda method. But looking at the javac changes in the patch, I don't quite see where this distinction between JDK 14 and patched JDK 15 javac comes from. From the changes to method com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: ??????????? final boolean needsConversionToLambda() { ??????????????? return interfaceParameterIsIntersectionOrUnionType() || ??????????????????????? isSuper || ??????????????????????? needsVarArgsConversion() || ??????????????????????? isArrayOp() || #??????????????????????? isPrivateInOtherClass() || isProtectedInSuperClassOfEnclosingClassInOtherPackage() || ??????????????????????? !receiverAccessible() || ??????????????????????? (tree.getMode() == ReferenceMode.NEW && ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && ????????????????????????? (tree.sym.owner.isLocal() || tree.sym.owner.isInner())); ??????????? } ...I would draw the conclusion that conversion to lambda is performed in less cases not in more. Hm. Regards, Peter On 4/3/20 11:11 AM, Peter Levart wrote: > Hi Mandy, > > Good work. > > I'm trying to find out which language use-case is covered by the > InnerClassLambdaMetafactory needing to inject method handle into the > generated proxy class to be invoked instead of proxy class directly > invoking the method: > > ??????? useImplMethodHandle = > !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) > ??????????????????????????????? && > !Modifier.isPublic(implInfo.getModifiers()); > > If I check what implClass and implInfo get resolved to in > AbstractValidatingLambdaMetafactory, there are several cases: > > ??????? this.implInfo = caller.revealDirect(implMethod); > ??????? switch (implInfo.getReferenceKind()) { > ??????????? case REF_invokeVirtual: > ??????????? case REF_invokeInterface: > ??????????????? this.implClass = implMethodType.parameterType(0); > ??????????????? // reference kind reported by implInfo may not match > implMethodType's first param > ??????????????? // Example: implMethodType is (Cloneable)String, > implInfo is for Object.toString > ??????????????? this.implKind = implClass.isInterface() ? > REF_invokeInterface : REF_invokeVirtual; > ??????????????? this.implIsInstanceMethod = true; > ??????????????? break; > ??????????? case REF_invokeSpecial: > ??????????????? // JDK-8172817: should use referenced class here, but > we don't know what it was > ??????????????? this.implClass = implInfo.getDeclaringClass(); > ??????????????? this.implIsInstanceMethod = true; > > ??????????????? // Classes compiled prior to dynamic nestmate support > invokes a private instance > ??????????????? // method with REF_invokeSpecial. > ??????????????? // > ??????????????? // invokespecial should only be used to invoke private > nestmate constructors. > ??????????????? // The lambda proxy class will be defined as a > nestmate of targetClass. > ??????????????? // If the method to be invoked is an instance method > of targetClass, then > ??????????????? // convert to use invokevirtual or invokeinterface. > ??????????????? if (targetClass == implClass && > !implInfo.getName().equals("")) { > ??????????????????? this.implKind = implClass.isInterface() ? > REF_invokeInterface : REF_invokeVirtual; > ??????????????? } else { > ??????????????????? this.implKind = REF_invokeSpecial; > ??????????????? } > ??????????????? break; > ??????????? case REF_invokeStatic: > ??????????? case REF_newInvokeSpecial: > ??????????????? // JDK-8172817: should use referenced class here for > invokestatic, but we don't know what it was > ??????????????? this.implClass = implInfo.getDeclaringClass(); > ??????????????? this.implKind = implInfo.getReferenceKind(); > ??????????????? this.implIsInstanceMethod = false; > ??????????????? break; > ??????????? default: > ??????????????? throw new > LambdaConversionException(String.format("Unsupported MethodHandle > kind: %s", implInfo)); > ??????? } > > > For majority of cases (REF_invokeSpecial, REF_invokeStatic, > REF_newInvokeSpecial) the this.implClass = implInfo.getDeclaringClass(); > > Only REF_invokeVirtual and REF_invokeInterface are possible > kandidates, right? > > So when does the implMethod type of parameter 0 differ from the > declaring class of the MethodHandleInfo cracked from that same > implMethod and in addition those two types leave in different packages? > > Regards, Peter > > > On 3/27/20 12:57 AM, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area.? Small changes are >> made in javac, VM compiler (intrinsification of >> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed >> and is in the finalized state (see specdiff and javadoc below for >> reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's >> point >> of view, a hidden class is a normal class except the following: >> >> - A hidden class has no initiating class loader and is not registered >> in any dictionary. >> - A hidden class has a name containing an illegal character >> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature` >> returns "Lp/Foo.0x1234;". >> - A hidden class is not modifiable, i.e. cannot be redefined or >> retransformed. JVM TI IsModifableClass returns false on a hidden. >> - Final fields in a hidden class is "final".? The value of final >> fields cannot be overriden via reflection.? setAccessible(true) can >> still be called on reflected objects representing final fields in a >> hidden class and its access check will be suppressed but only have >> read-access (i.e. can do Field::getXXX but not setXXX). >> >> Brief summary of this patch: >> >> 1. A new Lookup::defineHiddenClass method is the API to create a >> hidden class. >> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG >> option that >> ?? can be specified when creating a hidden class. >> 3. A new Class::isHiddenClass method tests if a class is a hidden class. >> 4. Field::setXXX method will throw IAE on a final field of a hidden >> class >> ?? regardless of the value of the accessible flag. >> 5. JVM_LookupDefineClass is the new JVM entry point for >> Lookup::defineClass >> ?? and defineHiddenClass to create a class from the given bytes. >> 6. ClassLoaderData implementation is not changed.? There is one >> primary CLD >> ?? that holds the classes strongly referenced by its defining >> loader.? There >> ?? can be zero or more additional CLDs - one per weak class. >> 7. Nest host determination is updated per revised JVMS 5.4.4. Access >> control >> ?? check no longer throws LinkageError but instead it will throw IAE >> with >> ?? a clear message if a class fails to resolve/validate the nest host >> declared >> ?? in NestHost/NestMembers attribute. >> 8. JFR, jcmd, JDI are updated to support hidden classes. >> 9. update javac LambdaToMethod as lambda proxy starts using nestmates >> ?? and generate a bridge method to desuger a method reference to a >> protected >> ?? method in its supertype in a different package >> >> This patch also updates StringConcatFactory, LambdaMetaFactory, and >> LambdaForms >> to use hidden classes.? The webrev includes changes in nashorn to >> hidden class >> and I will update the webrev if JEP 372 removes it any time soon. >> >> We uncovered a bug in Lookup::defineClass spec throws LinkageError >> and intends >> to have the newly created class linked.? However, the implementation >> in 14 >> does not link the class.? A separate CSR [2] proposes to update the >> implementation to match the spec.? This patch fixes the implementation. >> >> The spec update on JVM TI, JDI and Instrumentation will be done as >> a separate RFE [3].? This patch includes new tests for JVM TI and >> java.instrument that validates how the existing APIs work for hidden >> classes. >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > From daniil.x.titov at oracle.com Fri Apr 3 17:09:05 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 03 Apr 2020 10:09:05 -0700 Subject: 8241530: com/sun/jdi tests fail due to network issues on OSX 10.15 In-Reply-To: <17833356-c963-ee65-c7c8-f4a8c8c8c5f2@oracle.com> References: <84D85D3D-AFCA-42BD-BD02-35604E462D5F@oracle.com> <17833356-c963-ee65-c7c8-f4a8c8c8c5f2@oracle.com> Message-ID: <40045D9A-D02E-49E5-9711-E7DB351DECA0@oracle.com> Thank you, Serguei and Alex, for reviewing this change. Best regards, Daniil ?On 4/1/20, 2:19 PM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, LGTM++ Thanks, Serguei On 3/30/20 13:06, Alex Menkov wrote: > Looks good. > > --alex > > On 03/30/2020 12:43, Daniil Titov wrote: >> Please review the change [1] that fixes the failure of >> com/sun/jdi/JdwpListenTest.java >> and com/sun/jdi/JdwpAttachTest.java tests on OSX 10.15. >> >> The problem here is the similar to the one solved in [4] by >> additional filtering >> of unusual network interfaces in the test library class >> jdk.test.lib.NetworkConfiguration. >> However, the failing com/sun/jdi tests do not use >> jdk.test.lib.NetworkConfiguration and >> Instead do repeat the same logic themselves. >> >> The fix changes these tests to start using >> jdk.test.lib.NetworkConfiguration to find all local addresses. >> >> Initially the issue [2] also included 3 other failing tests from >> sun/management/jdp package, but these tests fail >> for a different reason so I moved them in the new issue [3] and >> updated the ProblemList.txt for them. >> >> >> [1] Webrev: http://cr.openjdk.java.net/~dtitov/8241530/webrev.01/ >> [2] Jira Issue: https://bugs.openjdk.java.net/browse/JDK-8241530 >> [3] https://bugs.openjdk.java.net/browse/JDK-8241865 >> [4] https://bugs.openjdk.java.net/browse/JDK-8241336 >> >> Thank you, >> Daniil >> >> From chris.plummer at oracle.com Fri Apr 3 17:35:23 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 3 Apr 2020 10:35:23 -0700 Subject: RFR(S) 8240989: convert clhsdb "dumpheap" command from javascript to java In-Reply-To: <6ff111c0-5eec-7462-e546-1fc40e262e58@oracle.com> References: <2471b2e2-d3f9-a771-6a7b-f644c1efd241@oracle.com> <03da99ea-6369-392a-5990-17eeaa16c40d@oss.nttdata.com> <6ff111c0-5eec-7462-e546-1fc40e262e58@oracle.com> Message-ID: <720ef5d5-0779-10c4-5c6b-65232288722a@oracle.com> Thanks Alex and Yasumasa! Chris On 4/2/20 5:35 PM, Alex Menkov wrote: > +1 > > --alex > > On 04/02/2020 17:17, Yasumasa Suenaga wrote: >> Hi Chris, >> >> Looks good! >> >> >> Yasumasa >> >> >> On 2020/04/03 5:46, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8240989 >>> http://cr.openjdk.java.net/~cjplummer/8240989/webrev.01/ >>> >>> See the CR for details. >>> >>> For the test I used ClhsdbField.java as a simple clhsdb template. To >>> verify the dumped heap I added the call to printStackTraces(), which >>> came from test/jdk/sun/tools/jhsdb/HeapDumpTest.java. >>> >>> thanks, >>> >>> Chris From chris.plummer at oracle.com Fri Apr 3 18:30:45 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 3 Apr 2020 11:30:45 -0700 Subject: RFR: 8241958: Slow ClassLoaderReferenceImpl.findType In-Reply-To: References: Message-ID: <4caeb5f1-aa6c-63ef-cd33-692a6badcaf5@oracle.com> Hi Egor, The changes look fine. Please update the copyrights before pushing. thanks, Chris On 4/3/20 2:16 AM, Egor Ushakov wrote: > Hi all, please review the fix > > The com.sun.tools.jdi.ClassLoaderReferenceImpl#findType may be slow > because ClassLoaderReferenceImpl#visibleClasses does not populate > signature and we check it for every class in the loop just after, so > requesting all unavailable signatures one by one. > The fix adds extra check in classesBySignature before comparing > signatures of all visible classes. > > bugid https://bugs.openjdk.java.net/browse/JDK-8241958 > cr http://cr.openjdk.java.net/~eushakov/8241958/webrev.00/ > > Thanks! > From chris.plummer at oracle.com Fri Apr 3 19:49:35 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 3 Apr 2020 12:49:35 -0700 Subject: RFR: JDK-8237572: Combine the two LingeredApp classes In-Reply-To: <3ba8b09b-2570-86cb-6fc5-65e41947c77d@oracle.com> References: <3ba8b09b-2570-86cb-6fc5-65e41947c77d@oracle.com> Message-ID: <138344f6-9a73-ee74-be41-f79d101aad1a@oracle.com> Looks good. thanks, Chris On 4/2/20 4:20 PM, Alex Menkov wrote: > Hi all, > > please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8237572 > webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/jpsLingeredApp/webrev/ > > verified all test which use LangeredApp pass. > > --alex From leonid.mesnik at oracle.com Fri Apr 3 20:15:00 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 3 Apr 2020 13:15:00 -0700 Subject: RFR: JDK-8237572: Combine the two LingeredApp classes In-Reply-To: <3ba8b09b-2570-86cb-6fc5-65e41947c77d@oracle.com> References: <3ba8b09b-2570-86cb-6fc5-65e41947c77d@oracle.com> Message-ID: <9FF9C2AE-FBAE-49F3-B138-C9593AC518F7@oracle.com> Looks good Leonid > On Apr 2, 2020, at 4:20 PM, Alex Menkov wrote: > > Hi all, > > please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8237572 > webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/jpsLingeredApp/webrev/ > > verified all test which use LangeredApp pass. > > --alex From mandy.chung at oracle.com Fri Apr 3 21:32:48 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 3 Apr 2020 14:32:48 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> Message-ID: <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Hi Peter, I added a JBS comment [1] to describe this special case trying to put the story together (let me know if it needs more explanation). More comment inline below. On 4/3/20 4:40 AM, Peter Levart wrote: > Ok, I think I found one such use-case. In the following example: > > package test; > public class LambdaTest { > ??? protected void m() { > ??? } > } > > package test.sub; > public class LambdaTestSub extends test.LambdaTest { > ??? public void test() { > ??????? Runnable r = this::m; > ??????? r.run(); > ??? } > } Yes. This is specific for binary compatibility.?? the invocation of a protected method inherited from its supertype in a different package. The lambda proxy is in the same package as the target class (`test.sub` in the example above) but it has no access to `test.LambdaTest::m`. > > ...when compiled with JDK 14 javac. In this case the implClass is > test.sub.LambdaTestSub while implInfo is "invokeVirtual > test.LambdaTest.m:()void" and the method is not public. > In JDK 14, a lambda proxy `test.sub.LambdaTestSub$Lambda$$1234` is VM anonymous class which has a special powerful access as if the host class.?? This proxy class, even though it's not an instance of `test.LambdaTest`, can invoke? the protected`test.LambdaTest.m:()void` member. > Anyway, the name of the proxy class is derived from the targetClass > (and therefore shares the same package with targetClass) which is > caller's lookup class. Is targetClass always the same as implClass in > the invokeVirtual/invokeInterface case? > implMethod is the direct method handle describing the implementation method resolved by the VM.?? So it depends. In the above example, it's `test.LambdaTest.m:()void` and implClass is test.LambdaTest.? The targetClass is test.sub.LambdaTestSub which is *NOT* the same as implClass.? That's why we change if they are in the same package. It can be invoking a method in targetClass or a method in another class in the same package with package access, then implClass may or may not be the same as targetClass. > I also noticed that JDK 15 patched javac transforms method reference > in above code into a lambda method. But looking at the javac changes > in the patch, I don't quite see where this distinction between JDK 14 > and patched JDK 15 javac comes from. javac has been changed in JDK 14 to synthesize a bridge method if it's a method reference to access a protected member in a remote supertype? (JDK-8234729). BTW, the new tests relevant to this scenario are under test/jdk/java/lang/invoke/lambda/superProtectedMethod. > From the changes to method > com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: > > ??????????? final boolean needsConversionToLambda() { > ??????????????? return interfaceParameterIsIntersectionOrUnionType() || > ??????????????????????? isSuper || > ??????????????????????? needsVarArgsConversion() || > ??????????????????????? isArrayOp() || > #??????????????????????? isPrivateInOtherClass() || > isProtectedInSuperClassOfEnclosingClassInOtherPackage() || > ??????????????????????? !receiverAccessible() || > ??????????????????????? (tree.getMode() == ReferenceMode.NEW && > ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && > ????????????????????????? (tree.sym.owner.isLocal() || > tree.sym.owner.isInner())); > ??????????? } > > ...I would draw the conclusion that conversion to lambda is performed > in less cases not in more. Jan and Srikanath may be able to explain this further. > Hm. > > Regards, Peter > > On 4/3/20 11:11 AM, Peter Levart wrote: >> Hi Mandy, >> >> Good work. >> >> I'm trying to find out which language use-case is covered by the >> InnerClassLambdaMetafactory needing to inject method handle into the >> generated proxy class to be invoked instead of proxy class directly >> invoking the method: >> >> ??????? useImplMethodHandle = >> !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) >> ??????????????????????????????? && >> !Modifier.isPublic(implInfo.getModifiers()); >> >> If I check what implClass and implInfo get resolved to in >> AbstractValidatingLambdaMetafactory, there are several cases: >> >> ??????? this.implInfo = caller.revealDirect(implMethod); >> ??????? switch (implInfo.getReferenceKind()) { >> ??????????? case REF_invokeVirtual: >> ??????????? case REF_invokeInterface: >> ??????????????? this.implClass = implMethodType.parameterType(0); >> ??????????????? // reference kind reported by implInfo may not match >> implMethodType's first param >> ??????????????? // Example: implMethodType is (Cloneable)String, >> implInfo is for Object.toString >> ??????????????? this.implKind = implClass.isInterface() ? >> REF_invokeInterface : REF_invokeVirtual; >> ??????????????? this.implIsInstanceMethod = true; >> ??????????????? break; >> ??????????? case REF_invokeSpecial: >> ??????????????? // JDK-8172817: should use referenced class here, but >> we don't know what it was >> ??????????????? this.implClass = implInfo.getDeclaringClass(); >> ??????????????? this.implIsInstanceMethod = true; >> >> ??????????????? // Classes compiled prior to dynamic nestmate support >> invokes a private instance >> ??????????????? // method with REF_invokeSpecial. >> ??????????????? // >> ??????????????? // invokespecial should only be used to invoke >> private nestmate constructors. >> ??????????????? // The lambda proxy class will be defined as a >> nestmate of targetClass. >> ??????????????? // If the method to be invoked is an instance method >> of targetClass, then >> ??????????????? // convert to use invokevirtual or invokeinterface. >> ??????????????? if (targetClass == implClass && >> !implInfo.getName().equals("")) { >> ??????????????????? this.implKind = implClass.isInterface() ? >> REF_invokeInterface : REF_invokeVirtual; >> ??????????????? } else { >> ??????????????????? this.implKind = REF_invokeSpecial; >> ??????????????? } >> ??????????????? break; >> ??????????? case REF_invokeStatic: >> ??????????? case REF_newInvokeSpecial: >> ??????????????? // JDK-8172817: should use referenced class here for >> invokestatic, but we don't know what it was >> ??????????????? this.implClass = implInfo.getDeclaringClass(); >> ??????????????? this.implKind = implInfo.getReferenceKind(); >> ??????????????? this.implIsInstanceMethod = false; >> ??????????????? break; >> ??????????? default: >> ??????????????? throw new >> LambdaConversionException(String.format("Unsupported MethodHandle >> kind: %s", implInfo)); >> ??????? } >> >> >> For majority of cases (REF_invokeSpecial, REF_invokeStatic, >> REF_newInvokeSpecial) the this.implClass = implInfo.getDeclaringClass(); >> >> Only REF_invokeVirtual and REF_invokeInterface are possible >> kandidates, right? >> >> So when does the implMethod type of parameter 0 differ from the >> declaring class of the MethodHandleInfo cracked from that same >> implMethod and in addition those two types leave in different packages? >> This is concerning the instance method and so parameter 0 is what it wants to look at. >> Regards, Peter >> Hope this helps. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8239384?focusedCommentId=14328369&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14328369 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Apr 3 22:08:00 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 3 Apr 2020 15:08:00 -0700 Subject: RFR(S) 8242142: convert clhsdb "class" and "classes" commands from javascript to java Message-ID: <68751dbe-7c4d-f6ca-ca4f-652a15daa57e@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8242142 http://cr.openjdk.java.net/~cjplummer/8242142/webrev.00/ See the CR for details. Note the output for the "class" command looks like: ??? jdk/test/lib/apps/LingeredApp @0x0000000800bcb040 The output for "classes" is the same, except each class is listed. The output for "print " is kind of long, but includes the following line, which the test looks for to verify the "class" output. ??? public class jdk.test.lib.apps.LingeredApp @0x0000000800bcb040 thanks, Chris From alexey.menkov at oracle.com Sat Apr 4 00:44:17 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 3 Apr 2020 17:44:17 -0700 Subject: RFR(S) 8242142: convert clhsdb "class" and "classes" commands from javascript to java In-Reply-To: <68751dbe-7c4d-f6ca-ca4f-652a15daa57e@oracle.com> References: <68751dbe-7c4d-f6ca-ca4f-652a15daa57e@oracle.com> Message-ID: <42060553-4053-be92-1b79-3c7d3dd2c5f8@oracle.com> Hi Chris, The fix looks good. Couple minor notes about the test: 41 static final String APP_CLASSNAME = "jdk/test/lib/apps/LingeredApp"; 42 static final String APP_DOT_CLASSNAME = APP_CLASSNAME.replace('/', '.'); I'd make this static final String APP_DOT_CLASSNAME = LingeredApp.class.getName(); static final String APP_CLASSNAME = APP_DOT_CLASSNAME.replace('.', '/'); 52 theApp = new LingeredApp(); 53 LingeredApp.startApp(theApp); can be just theApp = LingeredApp.startApp(); --alex On 04/03/2020 15:08, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242142 > http://cr.openjdk.java.net/~cjplummer/8242142/webrev.00/ > > See the CR for details. Note the output for the "class" command looks like: > > ??? jdk/test/lib/apps/LingeredApp @0x0000000800bcb040 > > The output for "classes" is the same, except each class is listed. The > output for "print " is kind of long, but includes the > following line, which the test looks for to verify the "class" output. > > ??? public class jdk.test.lib.apps.LingeredApp @0x0000000800bcb040 > > thanks, > > Chris > From chris.plummer at oracle.com Sat Apr 4 01:13:39 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 3 Apr 2020 18:13:39 -0700 (PDT) Subject: RFR(S) 8242142: convert clhsdb "class" and "classes" commands from javascript to java In-Reply-To: <42060553-4053-be92-1b79-3c7d3dd2c5f8@oracle.com> References: <68751dbe-7c4d-f6ca-ca4f-652a15daa57e@oracle.com> <42060553-4053-be92-1b79-3c7d3dd2c5f8@oracle.com> Message-ID: <33fa6271-1de5-9233-5d45-62f4dfd2b369@oracle.com> Ok, I'll make those changes. Thanks for the review. Chris On 4/3/20 5:44 PM, Alex Menkov wrote: > Hi Chris, > > The fix looks good. > Couple minor notes about the test: > > ?41???? static final String APP_CLASSNAME = > "jdk/test/lib/apps/LingeredApp"; > ? 42???? static final String APP_DOT_CLASSNAME = > APP_CLASSNAME.replace('/', '.'); > > I'd make this > static final String APP_DOT_CLASSNAME = LingeredApp.class.getName(); > static final String APP_CLASSNAME = APP_DOT_CLASSNAME.replace('.', '/'); > > > > ?52???????????? theApp = new LingeredApp(); > ?53???????????? LingeredApp.startApp(theApp); > > can be just > > theApp = LingeredApp.startApp(); > > --alex > > On 04/03/2020 15:08, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8242142 >> http://cr.openjdk.java.net/~cjplummer/8242142/webrev.00/ >> >> See the CR for details. Note the output for the "class" command looks >> like: >> >> ???? jdk/test/lib/apps/LingeredApp @0x0000000800bcb040 >> >> The output for "classes" is the same, except each class is listed. >> The output for "print " is kind of long, but includes the >> following line, which the test looks for to verify the "class" output. >> >> ???? public class jdk.test.lib.apps.LingeredApp @0x0000000800bcb040 >> >> thanks, >> >> Chris >> From chris.plummer at oracle.com Sat Apr 4 01:56:22 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 3 Apr 2020 18:56:22 -0700 Subject: RFR(S) 8242142: convert clhsdb "class" and "classes" commands from javascript to java In-Reply-To: <33fa6271-1de5-9233-5d45-62f4dfd2b369@oracle.com> References: <68751dbe-7c4d-f6ca-ca4f-652a15daa57e@oracle.com> <42060553-4053-be92-1b79-3c7d3dd2c5f8@oracle.com> <33fa6271-1de5-9233-5d45-62f4dfd2b369@oracle.com> Message-ID: <017c1519-a238-ebf5-277c-9a8e7d53d7ba@oracle.com> Here's an updated webrev. I also renamed APP_CLASSNAME to APP_SLASH_CLASSNAME just to make it a bit more clear which format is being used. http://cr.openjdk.java.net/~cjplummer/8242142/webrev.01 thanks, Chris On 4/3/20 6:13 PM, Chris Plummer wrote: > Ok, I'll make those changes. Thanks for the review. > > Chris > > On 4/3/20 5:44 PM, Alex Menkov wrote: >> Hi Chris, >> >> The fix looks good. >> Couple minor notes about the test: >> >> ?41???? static final String APP_CLASSNAME = >> "jdk/test/lib/apps/LingeredApp"; >> ? 42???? static final String APP_DOT_CLASSNAME = >> APP_CLASSNAME.replace('/', '.'); >> >> I'd make this >> static final String APP_DOT_CLASSNAME = LingeredApp.class.getName(); >> static final String APP_CLASSNAME = APP_DOT_CLASSNAME.replace('.', '/'); >> >> >> >> ?52???????????? theApp = new LingeredApp(); >> ?53???????????? LingeredApp.startApp(theApp); >> >> can be just >> >> theApp = LingeredApp.startApp(); >> >> --alex >> >> On 04/03/2020 15:08, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8242142 >>> http://cr.openjdk.java.net/~cjplummer/8242142/webrev.00/ >>> >>> See the CR for details. Note the output for the "class" command >>> looks like: >>> >>> ???? jdk/test/lib/apps/LingeredApp @0x0000000800bcb040 >>> >>> The output for "classes" is the same, except each class is listed. >>> The output for "print " is kind of long, but includes the >>> following line, which the test looks for to verify the "class" output. >>> >>> ???? public class jdk.test.lib.apps.LingeredApp @0x0000000800bcb040 >>> >>> thanks, >>> >>> Chris >>> > > From chris.plummer at oracle.com Sat Apr 4 08:07:55 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 4 Apr 2020 01:07:55 -0700 Subject: RFR(XS) 8242153: ProblemList serviceability/sa/ClhsdbDumpheap.java on OSX Message-ID: <9610a581-6e2b-1058-fa17-aecb15d3d547@oracle.com> Hi, I just added this test, but it often fails due to a pre-existing SA bug on OSX that happens during heap dumps. It needs to be problem listed: diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt +++ b/test/hotspot/jtreg/ProblemList.txt @@ -102,7 +102,7 @@ ?serviceability/sa/ClhsdbCDSCore.java 8193639 solaris-all ?serviceability/sa/ClhsdbCDSJstackPrintAll.java 8193639 solaris-all ?serviceability/sa/CDSJMapClstats.java 8193639 solaris-all -serviceability/sa/ClhsdbDumpheap.java 8193639 solaris-all +serviceability/sa/ClhsdbDumpheap.java 8193639,8241158 solaris-all,macosx-x64 ?serviceability/sa/ClhsdbField.java 8193639 solaris-all ?serviceability/sa/ClhsdbFindPC.java#id0 8193639 solaris-all ?serviceability/sa/ClhsdbFindPC.java#id1 8193639 solaris-all thanks, Chris From peter.levart at gmail.com Sat Apr 4 10:58:15 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 4 Apr 2020 12:58:15 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Message-ID: Hi Mandy, On 4/3/20 11:32 PM, Mandy Chung wrote: > Hi Peter, > > I added a JBS comment [1] to describe this special case trying to put > the story together (let me know if it needs more explanation). ? More > comment inline below. Thanks, this helps in establishing the historical context. > > On 4/3/20 4:40 AM, Peter Levart wrote: >> Ok, I think I found one such use-case. In the following example: >> >> package test; >> public class LambdaTest { >> ??? protected void m() { >> ??? } >> } >> >> package test.sub; >> public class LambdaTestSub extends test.LambdaTest { >> ??? public void test() { >> ??????? Runnable r = this::m; >> ??????? r.run(); >> ??? } >> } > > Yes. > > This is specific for binary compatibility.?? the invocation of a > protected method inherited from its supertype in a different package. > > The lambda proxy is in the same package as the target class > (`test.sub` in the example above) but it has no access to > `test.LambdaTest::m`. > >> >> ...when compiled with JDK 14 javac. In this case the implClass is >> test.sub.LambdaTestSub while implInfo is "invokeVirtual >> test.LambdaTest.m:()void" and the method is not public. >> > > In JDK 14, a lambda proxy `test.sub.LambdaTestSub$Lambda$$1234` is VM > anonymous class which has a special powerful access as if the host > class.?? This proxy class, even though it's not an instance of > `test.LambdaTest`, can invoke? the protected`test.LambdaTest.m:()void` > member. Right, the VM anonymous class "inherits" all access rights from the host class, which in above example is the subclass of test.LambdaTes. > >> Anyway, the name of the proxy class is derived from the targetClass >> (and therefore shares the same package with targetClass) which is >> caller's lookup class. Is targetClass always the same as implClass in >> the invokeVirtual/invokeInterface case? >> > > implMethod is the direct method handle describing the implementation > method resolved by the VM.?? So it depends. > > In the above example, it's `test.LambdaTest.m:()void` and implClass is > test.LambdaTest. Here I think, you are not quite right. First I need to clarify that we are talking about the case where the method reference in above example is not converted to lambda by javac, so the proxy class needs to invoke the superclass method directly (without the help of lambda bridge). I did an experiment and compiled the example with JDK 13 javac, where the patch for (JDK-8234729) is not applied yet. What I get from this compilation is the following metafactory bootstrap method invocation: ? 0: #35 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; ??? Method arguments: ????? #42 ()V ????? #43 REF_invokeVirtual test/LambdaTest.m:()V ????? #42 ()V The #43 is the implMethod method handle and it is the following: ? #43 = MethodHandle?????? 5:#44????????? // REF_invokeVirtual test/LambdaTest.m:()V ? #44 = Methodref????????? #2.#45???????? // test/LambdaTest.m:()V ? #45 = NameAndType??????? #46:#6???????? // m:()V ? #46 = Utf8?????????????? m ?? #2 = Class????????????? #4???????????? // test/LambdaTest ?? #4 = Utf8?????????????? test/LambdaTest *BUT* the class that looks up this MH from the constant pool is the subclass (test.sub.LambdaTestSub) which is equivalent to the following programmatic lookup: ??????? var mh = MethodHandles.lookup().findVirtual(LambdaTest.class, "m", MethodType.methodType(void.class)); ??????? System.out.println(mh.type()); and this results in a method handle of the following type: (LambdaTestSub)void which is correct since the method handle *MUST* check that the passed in instance (this) is of type LambdaTestSub or subtype or else the "protected" access would be violated. And since the ref type is REF_invokeVirtual, the AbstractValidatingLambdaMetafactory assigns the following to the implClass: ??????? this.implMethodType = implMethod.type(); ??????? this.implInfo = caller.revealDirect(implMethod); ??????? switch (implInfo.getReferenceKind()) { ??????????? case REF_invokeVirtual: ??????????? case REF_invokeInterface: ??????????????? this.implClass = implMethodType.parameterType(0); ...which makes the implClass be LambdaTestSub in this case. Which is correct again since we want InnerClassLambdaMetafactory to decide that this is the special case for proxy to invoke the method via method handle: ??????? useImplMethodHandle = !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) ??????????????????????????????? && !Modifier.isPublic(implInfo.getModifiers()); If implClass was test.LambdaTest as you said above, this condition would evaluate to false, since implInfo is "invokeVirtual test.LambdaTest.m:()void" in above case. So everything is OK, but my original question was the following: The name of the generated proxy class is derived from the targetClass which is the caller's lookup class. In this example the caller is LambdaTestSub and this is the same as implClass in this case. Would those two classes always be the same in the case where the evaluation of the above `useImplMethodHandle` boolean matters? I mean, the decision about whether to base the proxy invocation strategy on method handle or direct bytecode invocation is based on one class (implClass), but the actual package of the proxy class which effectively influences the bytecode invocation rights is taken from another class (targetClass). On one hand the package of the proxy class has to be the same as targetClass if the proxy wants to be the nestmate of the targetClass (for example to have private access to the members of the nest). But OTOH it needs to be the same package also with implClass so that the above decision of the proxy invocation strategy is correct. I have a feeling that for protected virtual methods, this is true, because the type of the 0-argument of such method handle is always the lookup class. But am I right? What do you think of another alternative to invoking the super protected method in other package: What if the LMF would decide to base the name of the proxy class on the implInfo.getDeclaringClass() in such case? It would not have to be a nestmate of any class, just in the same package with the method's declaring class. Consequently it would be in the same module as the declaring class and loaded by the same class loader. Therefore it would have to be WEAKLY referenced from the class loader. And the Lookup instance passed to bootstrap LMF method would not be enough for defining such class. But LMF could obtain special powers since it is JDK internal class... Well, I don't know for myself. Is this situation rare enough so that invoking via method handle is not a drawback? It only happens when running JDK 13- compiled classes with JDK 15+ and in addition the method reference must point to protected method in a distant class. > The targetClass is test.sub.LambdaTestSub which is *NOT* the same as > implClass.? That's why we change if they are in the same package. > > It can be invoking a method in targetClass or a method in another > class in the same package with package access, then implClass may or > may not be the same as targetClass. > >> I also noticed that JDK 15 patched javac transforms method reference >> in above code into a lambda method. But looking at the javac changes >> in the patch, I don't quite see where this distinction between JDK 14 >> and patched JDK 15 javac comes from. > > javac has been changed in JDK 14 to synthesize a bridge method if it's > a method reference to access a protected member in a remote supertype? > (JDK-8234729). Ah, that was the reason I haven't seen the change in your patch. I used the JDK 13 javac and thought it would be the same as JDK 14 javac. My mistake. So this answers the question below... Regards, Peter > > BTW, the new tests relevant to this scenario are under > test/jdk/java/lang/invoke/lambda/superProtectedMethod. > >> From the changes to method >> com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: >> >> ??????????? final boolean needsConversionToLambda() { >> ??????????????? return interfaceParameterIsIntersectionOrUnionType() || >> ??????????????????????? isSuper || >> ??????????????????????? needsVarArgsConversion() || >> ??????????????????????? isArrayOp() || >> #??????????????????????? isPrivateInOtherClass() || >> isProtectedInSuperClassOfEnclosingClassInOtherPackage() || >> ??????????????????????? !receiverAccessible() || >> ??????????????????????? (tree.getMode() == ReferenceMode.NEW && >> ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && >> ????????????????????????? (tree.sym.owner.isLocal() || >> tree.sym.owner.isInner())); >> ??????????? } >> >> ...I would draw the conclusion that conversion to lambda is performed >> in less cases not in more. > > Jan and Srikanath may be able to explain this further. > >> Hm. >> >> Regards, Peter >> >> On 4/3/20 11:11 AM, Peter Levart wrote: >>> Hi Mandy, >>> >>> Good work. >>> >>> I'm trying to find out which language use-case is covered by the >>> InnerClassLambdaMetafactory needing to inject method handle into the >>> generated proxy class to be invoked instead of proxy class directly >>> invoking the method: >>> >>> ??????? useImplMethodHandle = >>> !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) >>> ??????????????????????????????? && >>> !Modifier.isPublic(implInfo.getModifiers()); >>> >>> If I check what implClass and implInfo get resolved to in >>> AbstractValidatingLambdaMetafactory, there are several cases: >>> >>> ??????? this.implInfo = caller.revealDirect(implMethod); >>> ??????? switch (implInfo.getReferenceKind()) { >>> ??????????? case REF_invokeVirtual: >>> ??????????? case REF_invokeInterface: >>> ??????????????? this.implClass = implMethodType.parameterType(0); >>> ??????????????? // reference kind reported by implInfo may not match >>> implMethodType's first param >>> ??????????????? // Example: implMethodType is (Cloneable)String, >>> implInfo is for Object.toString >>> ??????????????? this.implKind = implClass.isInterface() ? >>> REF_invokeInterface : REF_invokeVirtual; >>> ??????????????? this.implIsInstanceMethod = true; >>> ??????????????? break; >>> ??????????? case REF_invokeSpecial: >>> ??????????????? // JDK-8172817: should use referenced class here, >>> but we don't know what it was >>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>> ??????????????? this.implIsInstanceMethod = true; >>> >>> ??????????????? // Classes compiled prior to dynamic nestmate >>> support invokes a private instance >>> ??????????????? // method with REF_invokeSpecial. >>> ??????????????? // >>> ??????????????? // invokespecial should only be used to invoke >>> private nestmate constructors. >>> ??????????????? // The lambda proxy class will be defined as a >>> nestmate of targetClass. >>> ??????????????? // If the method to be invoked is an instance method >>> of targetClass, then >>> ??????????????? // convert to use invokevirtual or invokeinterface. >>> ??????????????? if (targetClass == implClass && >>> !implInfo.getName().equals("")) { >>> ??????????????????? this.implKind = implClass.isInterface() ? >>> REF_invokeInterface : REF_invokeVirtual; >>> ??????????????? } else { >>> ??????????????????? this.implKind = REF_invokeSpecial; >>> ??????????????? } >>> ??????????????? break; >>> ??????????? case REF_invokeStatic: >>> ??????????? case REF_newInvokeSpecial: >>> ??????????????? // JDK-8172817: should use referenced class here for >>> invokestatic, but we don't know what it was >>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>> ??????????????? this.implKind = implInfo.getReferenceKind(); >>> ??????????????? this.implIsInstanceMethod = false; >>> ??????????????? break; >>> ??????????? default: >>> ??????????????? throw new >>> LambdaConversionException(String.format("Unsupported MethodHandle >>> kind: %s", implInfo)); >>> ??????? } >>> >>> >>> For majority of cases (REF_invokeSpecial, REF_invokeStatic, >>> REF_newInvokeSpecial) the this.implClass = >>> implInfo.getDeclaringClass(); >>> >>> Only REF_invokeVirtual and REF_invokeInterface are possible >>> kandidates, right? >>> >>> So when does the implMethod type of parameter 0 differ from the >>> declaring class of the MethodHandleInfo cracked from that same >>> implMethod and in addition those two types leave in different packages? >>> > > This is concerning the instance method and so parameter 0 is what it > wants to look at. > >>> Regards, Peter >>> > > Hope this helps. > Mandy > [1] > https://bugs.openjdk.java.net/browse/JDK-8239384?focusedCommentId=14328369&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14328369 > > From daniel.daugherty at oracle.com Sat Apr 4 13:02:27 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 4 Apr 2020 09:02:27 -0400 Subject: RFR(XS) 8242153: ProblemList serviceability/sa/ClhsdbDumpheap.java on OSX In-Reply-To: <9610a581-6e2b-1058-fa17-aecb15d3d547@oracle.com> References: <9610a581-6e2b-1058-fa17-aecb15d3d547@oracle.com> Message-ID: <8ced3146-8215-8bc0-8cde-85c1cf3cfbd0@oracle.com> Thumbs up. This is a trivial fix. Dan On 4/4/20 4:07 AM, Chris Plummer wrote: > Hi, > > I just added this test, but it often fails due to a pre-existing SA > bug on OSX that happens during heap dumps. It needs to be problem listed: > > diff --git a/test/hotspot/jtreg/ProblemList.txt > b/test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -102,7 +102,7 @@ > ?serviceability/sa/ClhsdbCDSCore.java 8193639 solaris-all > ?serviceability/sa/ClhsdbCDSJstackPrintAll.java 8193639 solaris-all > ?serviceability/sa/CDSJMapClstats.java 8193639 solaris-all > -serviceability/sa/ClhsdbDumpheap.java 8193639 solaris-all > +serviceability/sa/ClhsdbDumpheap.java 8193639,8241158 > solaris-all,macosx-x64 > ?serviceability/sa/ClhsdbField.java 8193639 solaris-all > ?serviceability/sa/ClhsdbFindPC.java#id0 8193639 solaris-all > ?serviceability/sa/ClhsdbFindPC.java#id1 8193639 solaris-all > > thanks, > > Chris > From peter.levart at gmail.com Sat Apr 4 16:16:15 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 4 Apr 2020 18:16:15 +0200 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Message-ID: <60700e61-11da-164c-c192-eb8bb5ee71bb@gmail.com> Hi Mandy, Just another observation of the code in InnerClassLambdaMetafactory... For the useImplMethodHandle case you generate the protectedImplMethod static field to hold the MH and a static setter method: ??????????? mv = cw.visitMethod(ACC_PRIVATE + ACC_STATIC, ??????????????????????????????? "setImplMethod", DESCR_SET_IMPL_METHOD, ??????????????????????????????? null, null); ...but then later after you define the class you inject the MH via a "staticSetter" method handle: ??????????????? MethodHandle mh = lookup.findStaticSetter(lookup.lookupClass(), NAME_FIELD_IMPL_METHOD, MethodHandle.class); ??????????????? mh.invokeExact(implMethod); So you don't invoke the generated setter method but set the field via special kind of method handle (equivalent to putstatic bytecode). You can remove the setImplMethod method generation code. Regards, Peter On 4/4/20 12:58 PM, Peter Levart wrote: > Hi Mandy, > > On 4/3/20 11:32 PM, Mandy Chung wrote: >> Hi Peter, >> >> I added a JBS comment [1] to describe this special case trying to put >> the story together (let me know if it needs more explanation). ? More >> comment inline below. > > Thanks, this helps in establishing the historical context. > >> >> On 4/3/20 4:40 AM, Peter Levart wrote: >>> Ok, I think I found one such use-case. In the following example: >>> >>> package test; >>> public class LambdaTest { >>> ??? protected void m() { >>> ??? } >>> } >>> >>> package test.sub; >>> public class LambdaTestSub extends test.LambdaTest { >>> ??? public void test() { >>> ??????? Runnable r = this::m; >>> ??????? r.run(); >>> ??? } >>> } >> >> Yes. >> >> This is specific for binary compatibility.?? the invocation of a >> protected method inherited from its supertype in a different package. >> >> The lambda proxy is in the same package as the target class >> (`test.sub` in the example above) but it has no access to >> `test.LambdaTest::m`. >> >>> >>> ...when compiled with JDK 14 javac. In this case the implClass is >>> test.sub.LambdaTestSub while implInfo is "invokeVirtual >>> test.LambdaTest.m:()void" and the method is not public. >>> >> >> In JDK 14, a lambda proxy `test.sub.LambdaTestSub$Lambda$$1234` is VM >> anonymous class which has a special powerful access as if the host >> class.?? This proxy class, even though it's not an instance of >> `test.LambdaTest`, can invoke? the >> protected`test.LambdaTest.m:()void` member. > > Right, the VM anonymous class "inherits" all access rights from the > host class, which in above example is the subclass of test.LambdaTes. > >> >>> Anyway, the name of the proxy class is derived from the targetClass >>> (and therefore shares the same package with targetClass) which is >>> caller's lookup class. Is targetClass always the same as implClass >>> in the invokeVirtual/invokeInterface case? >>> >> >> implMethod is the direct method handle describing the implementation >> method resolved by the VM.?? So it depends. >> >> In the above example, it's `test.LambdaTest.m:()void` and implClass >> is test.LambdaTest. > > Here I think, you are not quite right. First I need to clarify that we > are talking about the case where the method reference in above example > is not converted to lambda by javac, so the proxy class needs to > invoke the superclass method directly (without the help of lambda > bridge). I did an experiment and compiled the example with JDK 13 > javac, where the patch for (JDK-8234729) is not applied yet. What I > get from this compilation is the following metafactory bootstrap > method invocation: > > ? 0: #35 REF_invokeStatic > java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > ??? Method arguments: > ????? #42 ()V > ????? #43 REF_invokeVirtual test/LambdaTest.m:()V > ????? #42 ()V > > The #43 is the implMethod method handle and it is the following: > > ? #43 = MethodHandle?????? 5:#44????????? // REF_invokeVirtual > test/LambdaTest.m:()V > ? #44 = Methodref????????? #2.#45???????? // test/LambdaTest.m:()V > ? #45 = NameAndType??????? #46:#6???????? // m:()V > ? #46 = Utf8?????????????? m > ?? #2 = Class????????????? #4???????????? // test/LambdaTest > ?? #4 = Utf8?????????????? test/LambdaTest > > *BUT* the class that looks up this MH from the constant pool is the > subclass (test.sub.LambdaTestSub) which is equivalent to the following > programmatic lookup: > > ??????? var mh = MethodHandles.lookup().findVirtual(LambdaTest.class, > "m", MethodType.methodType(void.class)); > ??????? System.out.println(mh.type()); > > and this results in a method handle of the following type: > (LambdaTestSub)void > > which is correct since the method handle *MUST* check that the passed > in instance (this) is of type LambdaTestSub or subtype or else the > "protected" access would be violated. > > And since the ref type is REF_invokeVirtual, the > AbstractValidatingLambdaMetafactory assigns the following to the > implClass: > > ??????? this.implMethodType = implMethod.type(); > ??????? this.implInfo = caller.revealDirect(implMethod); > ??????? switch (implInfo.getReferenceKind()) { > ??????????? case REF_invokeVirtual: > ??????????? case REF_invokeInterface: > ??????????????? this.implClass = implMethodType.parameterType(0); > > ...which makes the implClass be LambdaTestSub in this case. Which is > correct again since we want InnerClassLambdaMetafactory to decide that > this is the special case for proxy to invoke the method via method > handle: > > ??????? useImplMethodHandle = > !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) > ??????????????????????????????? && > !Modifier.isPublic(implInfo.getModifiers()); > > If implClass was test.LambdaTest as you said above, this condition > would evaluate to false, since implInfo is "invokeVirtual > test.LambdaTest.m:()void" in above case. > > So everything is OK, but my original question was the following: The > name of the generated proxy class is derived from the targetClass > which is the caller's lookup class. In this example the caller is > LambdaTestSub and this is the same as implClass in this case. Would > those two classes always be the same in the case where the evaluation > of the above `useImplMethodHandle` boolean matters? I mean, the > decision about whether to base the proxy invocation strategy on method > handle or direct bytecode invocation is based on one class > (implClass), but the actual package of the proxy class which > effectively influences the bytecode invocation rights is taken from > another class (targetClass). > > On one hand the package of the proxy class has to be the same as > targetClass if the proxy wants to be the nestmate of the targetClass > (for example to have private access to the members of the nest). But > OTOH it needs to be the same package also with implClass so that the > above decision of the proxy invocation strategy is correct. I have a > feeling that for protected virtual methods, this is true, because the > type of the 0-argument of such method handle is always the lookup > class. But am I right? > > What do you think of another alternative to invoking the super > protected method in other package: What if the LMF would decide to > base the name of the proxy class on the implInfo.getDeclaringClass() > in such case? It would not have to be a nestmate of any class, just in > the same package with the method's declaring class. Consequently it > would be in the same module as the declaring class and loaded by the > same class loader. Therefore it would have to be WEAKLY referenced > from the class loader. And the Lookup instance passed to bootstrap LMF > method would not be enough for defining such class. But LMF could > obtain special powers since it is JDK internal class... > > Well, I don't know for myself. Is this situation rare enough so that > invoking via method handle is not a drawback? It only happens when > running JDK 13- compiled classes with JDK 15+ and in addition the > method reference must point to protected method in a distant class. > >> The targetClass is test.sub.LambdaTestSub which is *NOT* the same as >> implClass.? That's why we change if they are in the same package. >> >> It can be invoking a method in targetClass or a method in another >> class in the same package with package access, then implClass may or >> may not be the same as targetClass. >> >>> I also noticed that JDK 15 patched javac transforms method reference >>> in above code into a lambda method. But looking at the javac changes >>> in the patch, I don't quite see where this distinction between JDK >>> 14 and patched JDK 15 javac comes from. >> >> javac has been changed in JDK 14 to synthesize a bridge method if >> it's a method reference to access a protected member in a remote >> supertype? (JDK-8234729). > > Ah, that was the reason I haven't seen the change in your patch. I > used the JDK 13 javac and thought it would be the same as JDK 14 > javac. My mistake. > > So this answers the question below... > > > Regards, Peter > >> >> BTW, the new tests relevant to this scenario are under >> test/jdk/java/lang/invoke/lambda/superProtectedMethod. >> >>> From the changes to method >>> com.sun.tools.javac.comp.LambdaToMethod.LambdaAnalyzerPreprocessor.ReferenceTranslationContext#needsConversionToLambda: >>> >>> ??????????? final boolean needsConversionToLambda() { >>> ??????????????? return interfaceParameterIsIntersectionOrUnionType() || >>> ??????????????????????? isSuper || >>> ??????????????????????? needsVarArgsConversion() || >>> ??????????????????????? isArrayOp() || >>> #??????????????????????? isPrivateInOtherClass() || >>> isProtectedInSuperClassOfEnclosingClassInOtherPackage() || >>> ??????????????????????? !receiverAccessible() || >>> ??????????????????????? (tree.getMode() == ReferenceMode.NEW && >>> ????????????????????????? tree.kind != ReferenceKind.ARRAY_CTOR && >>> ????????????????????????? (tree.sym.owner.isLocal() || >>> tree.sym.owner.isInner())); >>> ??????????? } >>> >>> ...I would draw the conclusion that conversion to lambda is >>> performed in less cases not in more. >> >> Jan and Srikanath may be able to explain this further. >> >>> Hm. >>> >>> Regards, Peter >>> >>> On 4/3/20 11:11 AM, Peter Levart wrote: >>>> Hi Mandy, >>>> >>>> Good work. >>>> >>>> I'm trying to find out which language use-case is covered by the >>>> InnerClassLambdaMetafactory needing to inject method handle into >>>> the generated proxy class to be invoked instead of proxy class >>>> directly invoking the method: >>>> >>>> ??????? useImplMethodHandle = >>>> !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) >>>> ??????????????????????????????? && >>>> !Modifier.isPublic(implInfo.getModifiers()); >>>> >>>> If I check what implClass and implInfo get resolved to in >>>> AbstractValidatingLambdaMetafactory, there are several cases: >>>> >>>> ??????? this.implInfo = caller.revealDirect(implMethod); >>>> ??????? switch (implInfo.getReferenceKind()) { >>>> ??????????? case REF_invokeVirtual: >>>> ??????????? case REF_invokeInterface: >>>> ??????????????? this.implClass = implMethodType.parameterType(0); >>>> ??????????????? // reference kind reported by implInfo may not >>>> match implMethodType's first param >>>> ??????????????? // Example: implMethodType is (Cloneable)String, >>>> implInfo is for Object.toString >>>> ??????????????? this.implKind = implClass.isInterface() ? >>>> REF_invokeInterface : REF_invokeVirtual; >>>> ??????????????? this.implIsInstanceMethod = true; >>>> ??????????????? break; >>>> ??????????? case REF_invokeSpecial: >>>> ??????????????? // JDK-8172817: should use referenced class here, >>>> but we don't know what it was >>>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>>> ??????????????? this.implIsInstanceMethod = true; >>>> >>>> ??????????????? // Classes compiled prior to dynamic nestmate >>>> support invokes a private instance >>>> ??????????????? // method with REF_invokeSpecial. >>>> ??????????????? // >>>> ??????????????? // invokespecial should only be used to invoke >>>> private nestmate constructors. >>>> ??????????????? // The lambda proxy class will be defined as a >>>> nestmate of targetClass. >>>> ??????????????? // If the method to be invoked is an instance >>>> method of targetClass, then >>>> ??????????????? // convert to use invokevirtual or invokeinterface. >>>> ??????????????? if (targetClass == implClass && >>>> !implInfo.getName().equals("")) { >>>> ??????????????????? this.implKind = implClass.isInterface() ? >>>> REF_invokeInterface : REF_invokeVirtual; >>>> ??????????????? } else { >>>> ??????????????????? this.implKind = REF_invokeSpecial; >>>> ??????????????? } >>>> ??????????????? break; >>>> ??????????? case REF_invokeStatic: >>>> ??????????? case REF_newInvokeSpecial: >>>> ??????????????? // JDK-8172817: should use referenced class here >>>> for invokestatic, but we don't know what it was >>>> ??????????????? this.implClass = implInfo.getDeclaringClass(); >>>> ??????????????? this.implKind = implInfo.getReferenceKind(); >>>> ??????????????? this.implIsInstanceMethod = false; >>>> ??????????????? break; >>>> ??????????? default: >>>> ??????????????? throw new >>>> LambdaConversionException(String.format("Unsupported MethodHandle >>>> kind: %s", implInfo)); >>>> ??????? } >>>> >>>> >>>> For majority of cases (REF_invokeSpecial, REF_invokeStatic, >>>> REF_newInvokeSpecial) the this.implClass = >>>> implInfo.getDeclaringClass(); >>>> >>>> Only REF_invokeVirtual and REF_invokeInterface are possible >>>> kandidates, right? >>>> >>>> So when does the implMethod type of parameter 0 differ from the >>>> declaring class of the MethodHandleInfo cracked from that same >>>> implMethod and in addition those two types leave in different >>>> packages? >>>> >> >> This is concerning the instance method and so parameter 0 is what it >> wants to look at. >> >>>> Regards, Peter >>>> >> >> Hope this helps. >> Mandy >> [1] >> https://bugs.openjdk.java.net/browse/JDK-8239384?focusedCommentId=14328369&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14328369 >> >> > From chris.plummer at oracle.com Sat Apr 4 16:23:44 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 4 Apr 2020 09:23:44 -0700 Subject: RFR(XS) 8242153: ProblemList serviceability/sa/ClhsdbDumpheap.java on OSX In-Reply-To: <8ced3146-8215-8bc0-8cde-85c1cf3cfbd0@oracle.com> References: <9610a581-6e2b-1058-fa17-aecb15d3d547@oracle.com> <8ced3146-8215-8bc0-8cde-85c1cf3cfbd0@oracle.com> Message-ID: <387e511b-9394-11fe-5c33-d8604813a5dc@oracle.com> Thanks! On 4/4/20 6:02 AM, Daniel D. Daugherty wrote: > Thumbs up. This is a trivial fix. > > Dan > > > On 4/4/20 4:07 AM, Chris Plummer wrote: >> Hi, >> >> I just added this test, but it often fails due to a pre-existing SA >> bug on OSX that happens during heap dumps. It needs to be problem >> listed: >> >> diff --git a/test/hotspot/jtreg/ProblemList.txt >> b/test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt >> +++ b/test/hotspot/jtreg/ProblemList.txt >> @@ -102,7 +102,7 @@ >> ?serviceability/sa/ClhsdbCDSCore.java 8193639 solaris-all >> ?serviceability/sa/ClhsdbCDSJstackPrintAll.java 8193639 solaris-all >> ?serviceability/sa/CDSJMapClstats.java 8193639 solaris-all >> -serviceability/sa/ClhsdbDumpheap.java 8193639 solaris-all >> +serviceability/sa/ClhsdbDumpheap.java 8193639,8241158 >> solaris-all,macosx-x64 >> ?serviceability/sa/ClhsdbField.java 8193639 solaris-all >> ?serviceability/sa/ClhsdbFindPC.java#id0 8193639 solaris-all >> ?serviceability/sa/ClhsdbFindPC.java#id1 8193639 solaris-all >> >> thanks, >> >> Chris >> > From mandy.chung at oracle.com Sat Apr 4 16:45:20 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 4 Apr 2020 09:45:20 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <60700e61-11da-164c-c192-eb8bb5ee71bb@gmail.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> <60700e61-11da-164c-c192-eb8bb5ee71bb@gmail.com> Message-ID: <53d28cd4-8e4e-b1bb-f218-a9f382ea9df6@oracle.com> On 4/4/20 9:16 AM, Peter Levart wrote: > Hi Mandy, > > Just another observation of the code in InnerClassLambdaMetafactory... > > For the useImplMethodHandle case you generate the protectedImplMethod > static field to hold the MH and a static setter method: > > ??????????? mv = cw.visitMethod(ACC_PRIVATE + ACC_STATIC, > ??????????????????????????????? "setImplMethod", DESCR_SET_IMPL_METHOD, > ??????????????????????????????? null, null); > > ...but then later after you define the class you inject the MH via a > "staticSetter" method handle: > > ??????????????? MethodHandle mh = > lookup.findStaticSetter(lookup.lookupClass(), NAME_FIELD_IMPL_METHOD, > MethodHandle.class); > ??????????????? mh.invokeExact(implMethod); > > So you don't invoke the generated setter method but set the field via > special kind of method handle (equivalent to putstatic bytecode). > You can remove the setImplMethod method generation code. > Good catch.?? Removed the unused method. Mandy > Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Sat Apr 4 18:15:14 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 4 Apr 2020 11:15:14 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <958f4c01-85a2-5d96-7221-c9549fae76f3@gmail.com> <1490090a-9e0e-b51b-03d6-088e479315be@oracle.com> Message-ID: <5fb01f1d-7d4d-b024-095a-4f429b2a06af@oracle.com> Hi Peter, On 4/4/20 3:58 AM, Peter Levart wrote: > > Here I think, you are not quite right. First I need to clarify that we > are talking about the case where the method reference in above example > is not converted to lambda by javac, so the proxy class needs to > invoke the superclass method directly (without the help of lambda > bridge). I did an experiment and compiled the example with JDK 13 > javac, where the patch for (JDK-8234729) is not applied yet. What I > get from this compilation is the following metafactory bootstrap > method invocation: > > ? 0: #35 REF_invokeStatic > java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > ??? Method arguments: > ????? #42 ()V > ????? #43 REF_invokeVirtual test/LambdaTest.m:()V > ????? #42 ()V > > The #43 is the implMethod method handle and it is the following: > > ? #43 = MethodHandle?????? 5:#44????????? // REF_invokeVirtual > test/LambdaTest.m:()V > ? #44 = Methodref????????? #2.#45???????? // test/LambdaTest.m:()V > ? #45 = NameAndType??????? #46:#6???????? // m:()V > ? #46 = Utf8?????????????? m > ?? #2 = Class????????????? #4???????????? // test/LambdaTest > ?? #4 = Utf8?????????????? test/LambdaTest > > *BUT* the class that looks up this MH from the constant pool is the > subclass (test.sub.LambdaTestSub) which is equivalent to the following > programmatic lookup: > > ??????? var mh = MethodHandles.lookup().findVirtual(LambdaTest.class, > "m", MethodType.methodType(void.class)); > ??????? System.out.println(mh.type()); > > and this results in a method handle of the following type: > (LambdaTestSub)void > > which is correct since the method handle *MUST* check that the passed > in instance (this) is of type LambdaTestSub or subtype or else the > "protected" access would be violated. > > And since the ref type is REF_invokeVirtual, the > AbstractValidatingLambdaMetafactory assigns the following to the > implClass: > > ??????? this.implMethodType = implMethod.type(); > ??????? this.implInfo = caller.revealDirect(implMethod); > ??????? switch (implInfo.getReferenceKind()) { > ??????????? case REF_invokeVirtual: > ??????????? case REF_invokeInterface: > ??????????????? this.implClass = implMethodType.parameterType(0); > > ...which makes the implClass be LambdaTestSub in this case. Which is > correct again since we want InnerClassLambdaMetafactory to decide that > this is the special case for proxy to invoke the method via method > handle: > > ??????? useImplMethodHandle = > !implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName()) > ??????????????????????????????? && > !Modifier.isPublic(implInfo.getModifiers()); > > If implClass was test.LambdaTest as you said above, this condition > would evaluate to false, since implInfo is "invokeVirtual > test.LambdaTest.m:()void" in above case. > My bad.? I mixed up with implClass and implInfo cracked from implMethod in your question. implInfo::getDeclaringClass() returns the declaring class of the resolved method, which is the superclass (which is what I have been thinking for test.LambdaTest). implClass is the target type of the method reference. AbstractValidatingLambdaMetafactory has clear comment: ??? final MethodType implMethodType;? // Type of the implMethod MethodHandle "(CC,int)String" ??? final Class implClass;???????????????? // Class for referencing the implementation method "class CC" > So everything is OK, but my original question was the following: The > name of the generated proxy class is derived from the targetClass > which is the caller's lookup class. In this example the caller is > LambdaTestSub and this is the same as implClass in this case. Yes. > Would those two classes always be the same in the case where the > evaluation of the above `useImplMethodHandle` boolean matters? I mean, > the decision about whether to base the proxy invocation strategy on > method handle or direct bytecode invocation is based on one class > (implClass), but the actual package of the proxy class which > effectively influences the bytecode invocation rights is taken from > another class (targetClass). > > On one hand the package of the proxy class has to be the same as > targetClass if the proxy wants to be the nestmate of the targetClass > (for example to have private access to the members of the nest). But > OTOH it needs to be the same package also with implClass so that the > above decision of the proxy invocation strategy is correct. I have a > feeling that for protected virtual methods, this is true, because the > type of the 0-argument of such method handle is always the lookup > class. But am I right? > > What do you think of another alternative to invoking the super > protected method in other package: What if the LMF would decide to > base the name of the proxy class on the implInfo.getDeclaringClass() > in such case? It would not have to be a nestmate of any class, just in > the same package with the method's declaring class. Consequently it > would be in the same module as the declaring class and loaded by the > same class loader. Therefore it would have to be WEAKLY referenced > from the class loader. And the Lookup instance passed to bootstrap LMF > method would not be enough for defining such class. But LMF could > obtain special powers since it is JDK internal class... > The implementation of the method reference invocation is logical part of the caller class.? I don't think spinning the proxy class in a remote package is the desirable thing to do (injecting a class from package A to package B). > Well, I don't know for myself. Is this situation rare enough so that > invoking via method handle is not a drawback? It only happens when > running JDK 13- compiled classes with JDK 15+ and in addition the > method reference must point to protected method in a distant class. There are other alternatives we considered.? This implementation is a just short term solution.? We plan to follow up some future enhancements that are the possible longer-term solutions for this issue. 1. JDK-8239580 evaluate the performance of direct method handle invocation rather than bytecode invocation for ALL cases Direct invocation of the `implMethod` method handle by the lambda proxy was explored in JDK 8 lambda development time. It is time to remeasure the performance of direct method handle invocation and re-evaluate that approach. 2.? JDK-8230501 class data support.? The live MethodHandle can be passed to the hidden class to replace the current implementation to set the implMethod in a static field of proxy class after it's defined. 3. JDK-8199386 enhance Lookup::in to support nestmates Hope this helps. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sun Apr 5 08:04:35 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 5 Apr 2020 01:04:35 -0700 Subject: RFR: 8241958: Slow ClassLoaderReferenceImpl.findType In-Reply-To: References: Message-ID: <9c6d1d89-3603-aca1-919d-c49538b2127c@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sun Apr 5 16:56:03 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 5 Apr 2020 09:56:03 -0700 Subject: RFR: 8241958: Slow ClassLoaderReferenceImpl.findType In-Reply-To: <9c6d1d89-3603-aca1-919d-c49538b2127c@oracle.com> References: <9c6d1d89-3603-aca1-919d-c49538b2127c@oracle.com> Message-ID: <75e2b5c0-47fe-66ba-032a-386bad287524@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Apr 6 05:49:56 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 5 Apr 2020 22:49:56 -0700 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties Message-ID: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> Hello, Please help review the following: https://bugs.openjdk.java.net/browse/JDK-8242165 http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 Please see the CR for an explanation of the bug and the fix. If you need some help with the SA code, let me know and I'll provide some details. It was pretty much all new to me, so I tried to put the needed details in the CR. For the test, I compare the list of properties dumped using 3 different methods to make sure the same set is dumped for each: 1. jhsdb jinfo --sysprops 2. jinfo -sysprops 3. Simple app (LingeredAppSysProps) that calls System.getProperties().list(System.out) The app output is considered the master list that is compared against the others, and I also make sure each list has the same number of properties. thanks, Chris From suenaga at oss.nttdata.com Mon Apr 6 06:41:31 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 6 Apr 2020 15:41:31 +0900 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> Message-ID: <49d65665-c94b-a087-0ac6-062484e5996a@oss.nttdata.com> Hi Chris, Almost your change looks good, but I have a question in TestSysProps.java. Can we conflict some keys in sysprops always? It is better if we can do so, but it is very difficult. Thanks, Yasumasa On 2020/04/06 14:49, Chris Plummer wrote: > Hello, > > Please help review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242165 > http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 > > Please see the CR for an explanation of the bug and the fix. If you need some help with the SA code, let me know and I'll provide some details. It was pretty much all new to me, so I tried to put the needed details in the CR. > > For the test, I compare the list of properties dumped using 3 different methods to make sure the same set is dumped for each: > > 1. jhsdb jinfo --sysprops > 2. jinfo -sysprops > 3. Simple app (LingeredAppSysProps) that calls System.getProperties().list(System.out) > > The app output is considered the master list that is compared against the others, and I also make sure each list has the same number of properties. > > thanks, > > Chris From chris.plummer at oracle.com Mon Apr 6 06:45:35 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 5 Apr 2020 23:45:35 -0700 Subject: 8242168: ClhsdbFindPC.java failed due to "RuntimeException: 'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr" Message-ID: <72f60c93-e8e4-d30a-9918-a6e3d1b6df54@oracle.com> Hello, Please help review the following: https://bugs.openjdk.java.net/browse/JDK-8242168 http://cr.openjdk.java.net/~cjplummer/8242168/webrev.00/ ClhsdbFindPC needs to be disabled when using -XX:+DeoptimizeALot because it means the expected compiled frame may not be compiled. I also fixed ClhsdbJstackXcompStress since it also relies on frames being compiled, although I never got it to fail since it managed to always find at least one compiled frame. I confirmed that with this fix these two tests are not run when -XX:+DeoptimizeALot is used. If not used, behavior is unchanged. ClhsdbFindPC.java#id0 runs whether or not using -Xcomp and #id1 still only runs when not using -Xcomp. ClhsdbJstackXcompStress gets run whether or not -Xcomp is used. thanks, Chris From chris.plummer at oracle.com Mon Apr 6 06:46:41 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 5 Apr 2020 23:46:41 -0700 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: <49d65665-c94b-a087-0ac6-062484e5996a@oss.nttdata.com> References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> <49d65665-c94b-a087-0ac6-062484e5996a@oss.nttdata.com> Message-ID: <4b8929d3-52e2-1e96-9d7d-30dc0fda5247@oracle.com> Hi Yasumasa, I'm not sure what you mean by "conflict some keys". Can you explain? thanks, Chris On 4/5/20 11:41 PM, Yasumasa Suenaga wrote: > Hi Chris, > > Almost your change looks good, but I have a question in > TestSysProps.java. > Can we conflict some keys in sysprops always? It is better if we can > do so, but it is very difficult. > > > Thanks, > > Yasumasa > > > On 2020/04/06 14:49, Chris Plummer wrote: >> Hello, >> >> Please help review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8242165 >> http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 >> >> Please see the CR for an explanation of the bug and the fix. If you >> need some help with the SA code, let me know and I'll provide some >> details. It was pretty much all new to me, so I tried to put the >> needed details in the CR. >> >> For the test, I compare the list of properties dumped using 3 >> different methods to make sure the same set is dumped for each: >> >> 1. jhsdb jinfo --sysprops >> 2. jinfo -sysprops >> 3. Simple app (LingeredAppSysProps) that calls >> System.getProperties().list(System.out) >> >> The app output is considered the master list that is compared against >> the others, and I also make sure each list has the same number of >> properties. >> >> thanks, >> >> Chris From chris.plummer at oracle.com Mon Apr 6 06:49:03 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 5 Apr 2020 23:49:03 -0700 Subject: RFR(XS) 8242168: ClhsdbFindPC.java failed due to "RuntimeException: 'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr" Message-ID: <94496cf9-61fa-103b-e2f8-3d1f6d36bdda@oracle.com> [Sorry about the resend. Subject wasn't quite right the first time.] Hello, Please help review the following: https://bugs.openjdk.java.net/browse/JDK-8242168 http://cr.openjdk.java.net/~cjplummer/8242168/webrev.00/ ClhsdbFindPC needs to be disabled when using -XX:+DeoptimizeALot because it means the expected compiled frame may not be compiled. I also fixed ClhsdbJstackXcompStress since it also relies on frames being compiled, although I never got it to fail since it managed to always find at least one compiled frame. I confirmed that with this fix these two tests are not run when -XX:+DeoptimizeALot is used. If not used, behavior is unchanged. ClhsdbFindPC.java#id0 runs whether or not using -Xcomp and #id1 still only runs when not using -Xcomp. ClhsdbJstackXcompStress gets run whether or not -Xcomp is used. thanks, Chris From chris.plummer at oracle.com Mon Apr 6 06:52:10 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 5 Apr 2020 23:52:10 -0700 Subject: 8242168: ClhsdbFindPC.java failed due to "RuntimeException: 'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr" In-Reply-To: <72f60c93-e8e4-d30a-9918-a6e3d1b6df54@oracle.com> References: <72f60c93-e8e4-d30a-9918-a6e3d1b6df54@oracle.com> Message-ID: <2eb8e41a-f0c1-89d8-2dcb-e7d3036eefb2@oracle.com> Please ignore this email and post on the other RFR thread I started. Chris On 4/5/20 11:45 PM, Chris Plummer wrote: > Hello, > > Please help review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242168 > http://cr.openjdk.java.net/~cjplummer/8242168/webrev.00/ > > ClhsdbFindPC needs to be disabled when using -XX:+DeoptimizeALot > because it means the expected compiled frame may not be compiled. I > also fixed ClhsdbJstackXcompStress since it also relies on frames > being compiled, although I never got it to fail since it managed to > always find at least one compiled frame. > > I confirmed that with this fix these two tests are not run when > -XX:+DeoptimizeALot is used. If not used, behavior is unchanged. > ClhsdbFindPC.java#id0 runs whether or not using -Xcomp and #id1 still > only runs when not using -Xcomp. ClhsdbJstackXcompStress gets run > whether or not -Xcomp is used. > > thanks, > > Chris From suenaga at oss.nttdata.com Mon Apr 6 06:56:04 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 6 Apr 2020 15:56:04 +0900 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: <4b8929d3-52e2-1e96-9d7d-30dc0fda5247@oracle.com> References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> <49d65665-c94b-a087-0ac6-062484e5996a@oss.nttdata.com> <4b8929d3-52e2-1e96-9d7d-30dc0fda5247@oracle.com> Message-ID: <01d65298-54cb-b0c2-94c9-caeb36818aee@oss.nttdata.com> Hi Chris, On 2020/04/06 15:46, Chris Plummer wrote: > Hi Yasumasa, > > I'm not sure what you mean by "conflict some keys". Can you explain? System properties stores in ConcurrentHashMap. `next` field would be used when hashcode of key string is conflicted. I think it would be better if we can add key strings which are different and have same hashcode. Thanks, Yasumasa > thanks, > > Chris > > On 4/5/20 11:41 PM, Yasumasa Suenaga wrote: >> Hi Chris, >> >> Almost your change looks good, but I have a question in TestSysProps.java. >> Can we conflict some keys in sysprops always? It is better if we can do so, but it is very difficult. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/06 14:49, Chris Plummer wrote: >>> Hello, >>> >>> Please help review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8242165 >>> http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 >>> >>> Please see the CR for an explanation of the bug and the fix. If you need some help with the SA code, let me know and I'll provide some details. It was pretty much all new to me, so I tried to put the needed details in the CR. >>> >>> For the test, I compare the list of properties dumped using 3 different methods to make sure the same set is dumped for each: >>> >>> 1. jhsdb jinfo --sysprops >>> 2. jinfo -sysprops >>> 3. Simple app (LingeredAppSysProps) that calls System.getProperties().list(System.out) >>> >>> The app output is considered the master list that is compared against the others, and I also make sure each list has the same number of properties. >>> >>> thanks, >>> >>> Chris > From chris.plummer at oracle.com Mon Apr 6 07:18:21 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Apr 2020 00:18:21 -0700 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: <01d65298-54cb-b0c2-94c9-caeb36818aee@oss.nttdata.com> References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> <49d65665-c94b-a087-0ac6-062484e5996a@oss.nttdata.com> <4b8929d3-52e2-1e96-9d7d-30dc0fda5247@oracle.com> <01d65298-54cb-b0c2-94c9-caeb36818aee@oss.nttdata.com> Message-ID: Hi Yasumasa, On 4/5/20 11:56 PM, Yasumasa Suenaga wrote: > Hi Chris, > > On 2020/04/06 15:46, Chris Plummer wrote: >> Hi Yasumasa, >> >> I'm not sure what you mean by "conflict some keys". Can you explain? > > System properties stores in ConcurrentHashMap. `next` field would be > used when hashcode of key string is conflicted. Yes, but are referring to how System Properties are stored, which is determined by the implementation of java.lang.System. SA cannot control that, but it must mimic the java.lang.System implementation. That means when SA fetches the System::_props field, it needs to know what type of data structure it points to. It thought it pointed to a hash table that used a rehash function (which maybe it did at one point), but it actually points to a hash table that uses chains (link lists) instead of rehashing. > I think it would be better if we can add key strings which are > different and have same hashcode. That's what it does. The property Nodes are chained when more than one property hashes to the same hast table index. The problem was that SA didn't realize they were chained so only saw the first property in the chain. thanks, Chris > > > Thanks, > > Yasumasa > > >> thanks, >> >> Chris >> >> On 4/5/20 11:41 PM, Yasumasa Suenaga wrote: >>> Hi Chris, >>> >>> Almost your change looks good, but I have a question in >>> TestSysProps.java. >>> Can we conflict some keys in sysprops always? It is better if we can >>> do so, but it is very difficult. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/04/06 14:49, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please help review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8242165 >>>> http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 >>>> >>>> Please see the CR for an explanation of the bug and the fix. If you >>>> need some help with the SA code, let me know and I'll provide some >>>> details. It was pretty much all new to me, so I tried to put the >>>> needed details in the CR. >>>> >>>> For the test, I compare the list of properties dumped using 3 >>>> different methods to make sure the same set is dumped for each: >>>> >>>> 1. jhsdb jinfo --sysprops >>>> 2. jinfo -sysprops >>>> 3. Simple app (LingeredAppSysProps) that calls >>>> System.getProperties().list(System.out) >>>> >>>> The app output is considered the master list that is compared >>>> against the others, and I also make sure each list has the same >>>> number of properties. >>>> >>>> thanks, >>>> >>>> Chris >> From suenaga at oss.nttdata.com Mon Apr 6 08:05:17 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 6 Apr 2020 17:05:17 +0900 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> <49d65665-c94b-a087-0ac6-062484e5996a@oss.nttdata.com> <4b8929d3-52e2-1e96-9d7d-30dc0fda5247@oracle.com> <01d65298-54cb-b0c2-94c9-caeb36818aee@oss.nttdata.com> Message-ID: <817d293f-cb8b-02a7-25e9-822c7246935d@oss.nttdata.com> Hi Chris, Thank you for explanation. I think it is difficult to store the property in same hashcode. So your change looks good. Yasumasa On 2020/04/06 16:18, Chris Plummer wrote: > Hi Yasumasa, > > On 4/5/20 11:56 PM, Yasumasa Suenaga wrote: >> Hi Chris, >> >> On 2020/04/06 15:46, Chris Plummer wrote: >>> Hi Yasumasa, >>> >>> I'm not sure what you mean by "conflict some keys". Can you explain? >> >> System properties stores in ConcurrentHashMap. `next` field would be used when hashcode of key string is conflicted. > Yes, but are referring to how System Properties are stored, which is determined by the implementation of java.lang.System. SA cannot control that, but it must mimic the java.lang.System implementation. That means when SA fetches the System::_props field, it needs to know what type of data structure it points to. It thought it pointed to a hash table that used a rehash function (which maybe it did at one point), but it actually points to a hash table that uses chains (link lists) instead of rehashing. >> I think it would be better if we can add key strings which are different and have same hashcode. > That's what it does. The property Nodes are chained when more than one property hashes to the same hast table index. The problem was that SA didn't realize they were chained so only saw the first property in the chain. > > thanks, > > Chris >> >> >> Thanks, >> >> Yasumasa >> >> >>> thanks, >>> >>> Chris >>> >>> On 4/5/20 11:41 PM, Yasumasa Suenaga wrote: >>>> Hi Chris, >>>> >>>> Almost your change looks good, but I have a question in TestSysProps.java. >>>> Can we conflict some keys in sysprops always? It is better if we can do so, but it is very difficult. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/04/06 14:49, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please help review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8242165 >>>>> http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 >>>>> >>>>> Please see the CR for an explanation of the bug and the fix. If you need some help with the SA code, let me know and I'll provide some details. It was pretty much all new to me, so I tried to put the needed details in the CR. >>>>> >>>>> For the test, I compare the list of properties dumped using 3 different methods to make sure the same set is dumped for each: >>>>> >>>>> 1. jhsdb jinfo --sysprops >>>>> 2. jinfo -sysprops >>>>> 3. Simple app (LingeredAppSysProps) that calls System.getProperties().list(System.out) >>>>> >>>>> The app output is considered the master list that is compared against the others, and I also make sure each list has the same number of properties. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>> > From serguei.spitsyn at oracle.com Mon Apr 6 16:56:45 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Apr 2020 09:56:45 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Apr 6 17:05:47 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Apr 2020 10:05:47 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Apr 6 17:50:08 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Apr 2020 10:50:08 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Apr 6 17:57:03 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Apr 2020 10:57:03 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> Message-ID: <93aca329-cf62-a199-4744-5a86f0b96998@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Apr 6 18:00:52 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Apr 2020 11:00:52 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <93aca329-cf62-a199-4744-5a86f0b96998@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <93aca329-cf62-a199-4744-5a86f0b96998@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Apr 6 18:12:55 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Apr 2020 11:12:55 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <93aca329-cf62-a199-4744-5a86f0b96998@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon Apr 6 18:54:11 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 6 Apr 2020 11:54:11 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <93aca329-cf62-a199-4744-5a86f0b96998@oracle.com> Message-ID: On 4/6/20 9:56 AM, serguei.spitsyn at oracle.com wrote: > > The suggested fix is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-regression-8242166.1/ > This patch looks okay. I'll include in my local patch. On 4/6/20 11:00 AM, Chris Plummer wrote: > > I think that's fine but I don't think it should be done in the context > of this Vahalla webrev since it has nothing to do with Vahalla. I'd > suggest filing an RFE and pushing it to jdk/jdk. Easier to track that > way if there are issues down the road. > I am okay to follow up as a separate RFE. thanks Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Apr 6 19:08:46 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Apr 2020 12:08:46 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <93aca329-cf62-a199-4744-5a86f0b96998@oracle.com> Message-ID: On 4/6/20 11:54, Mandy Chung wrote: > On 4/6/20 9:56 AM, serguei.spitsyn at oracle.com wrote: >> >> The suggested fix is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-regression-8242166.1/ >> > > This patch looks okay. I'll include in my local patch. > > On 4/6/20 11:00 AM, Chris Plummer wrote: >> >> I think that's fine but I don't think it should be done in the >> context of this Vahalla webrev since it has nothing to do with >> Vahalla. I'd suggest filing an RFE and pushing it to jdk/jdk. Easier >> to track that way if there are issues down the road. >> > > I am okay to follow up as a separate RFE. Filed RFE: ? https://bugs.openjdk.java.net/browse/JDK-8242241 ??? add assert to ClassUnloadEventImpl::className Thanks, Serguei > > thanks > Mandy From chris.plummer at oracle.com Mon Apr 6 20:10:35 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Apr 2020 13:10:35 -0700 Subject: RFR(S) 8242235: Disable SA testing on Solaris. Remove JDK-8193639 entries from ProblemList.txt Message-ID: <213cbe04-beb1-bc55-a34e-14789426a294@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8242235 http://cr.openjdk.java.net/~cjplummer/8242235/webrev.00 The SA problem list entries due to JDK-8193639 [1] have been a burden to maintain, and are badly out of date. Easiest solution is to remove them and disable SA testing on Solaris, which is what all the entries were suppose to be doing in the first place (although not always correctly). Once this change is pushed, I'll add a note to JDK-8193639 [1] so anyone working on it will know to undo the change in Platform.java. [1] https://bugs.openjdk.java.net/browse/JDK-8193639 thanks, Chris From daniel.daugherty at oracle.com Mon Apr 6 20:21:30 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Apr 2020 16:21:30 -0400 Subject: RFR(S) 8242235: Disable SA testing on Solaris. Remove JDK-8193639 entries from ProblemList.txt In-Reply-To: <213cbe04-beb1-bc55-a34e-14789426a294@oracle.com> References: <213cbe04-beb1-bc55-a34e-14789426a294@oracle.com> Message-ID: <28a65798-b46e-d482-4ece-09906d0ada78@oracle.com> On 4/6/20 4:10 PM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242235 > http://cr.openjdk.java.net/~cjplummer/8242235/webrev.00 test/hotspot/jtreg/ProblemList.txt ??? No comments. test/jdk/ProblemList.txt ??? No comments. test/lib/jdk/test/lib/Platform.java ??? No comments. Thumbs up. In the bug report, you said: > although due to test renames, moves, and additions, there are actually > still about 8 tests running on Solaris, but they shouldn't be. Perhaps those 8 tests are not affected by the bug that causes JDK-8193639. I don't see any recent links to JDK-8193639 that are valid failures. There are some links to JDK-8193639 for non-Solaris platforms which means those links are wrong, but none for Solaris (that I see). Dan > > The SA problem list entries due to JDK-8193639 [1] have been a burden > to maintain, and are badly out of date. Easiest solution is to remove > them and disable SA testing on Solaris, which is what all the entries > were suppose to be doing in the first place (although not always > correctly). > > Once this change is pushed, I'll add a note to JDK-8193639 [1] so > anyone working on it will know to undo the change in Platform.java. > > [1] https://bugs.openjdk.java.net/browse/JDK-8193639 > > thanks, > > Chris From leonid.mesnik at oracle.com Mon Apr 6 20:35:00 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 6 Apr 2020 13:35:00 -0700 Subject: RFR(XS) 8242168: ClhsdbFindPC.java failed due to "RuntimeException: 'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr" In-Reply-To: <94496cf9-61fa-103b-e2f8-3d1f6d36bdda@oracle.com> References: <94496cf9-61fa-103b-e2f8-3d1f6d36bdda@oracle.com> Message-ID: Looks good (not a Reviewer). Leonid On 4/5/20 11:49 PM, Chris Plummer wrote: > [Sorry about the resend. Subject wasn't quite right the first time.] > > Hello, > > Please help review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242168 > http://cr.openjdk.java.net/~cjplummer/8242168/webrev.00/ > > ClhsdbFindPC needs to be disabled when using -XX:+DeoptimizeALot > because it means the expected compiled frame may not be compiled. I > also fixed ClhsdbJstackXcompStress since it also relies on frames > being compiled, although I never got it to fail since it managed to > always find at least one compiled frame. > > I confirmed that with this fix these two tests are not run when > -XX:+DeoptimizeALot is used. If not used, behavior is unchanged. > ClhsdbFindPC.java#id0 runs whether or not using -Xcomp and #id1 still > only runs when not using -Xcomp. ClhsdbJstackXcompStress gets run > whether or not -Xcomp is used. > > thanks, > > Chris From alexey.menkov at oracle.com Mon Apr 6 20:35:18 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 6 Apr 2020 13:35:18 -0700 Subject: RFR(S) 8242235: Disable SA testing on Solaris. Remove JDK-8193639 entries from ProblemList.txt In-Reply-To: <213cbe04-beb1-bc55-a34e-14789426a294@oracle.com> References: <213cbe04-beb1-bc55-a34e-14789426a294@oracle.com> Message-ID: <7d0794cb-ef75-d4a1-4a24-90ad2028bdd5@oracle.com> LGTM --alex On 04/06/2020 13:10, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242235 > http://cr.openjdk.java.net/~cjplummer/8242235/webrev.00 > > The SA problem list entries due to JDK-8193639 [1] have been a burden to > maintain, and are badly out of date. Easiest solution is to remove them > and disable SA testing on Solaris, which is what all the entries were > suppose to be doing in the first place (although not always correctly). > > Once this change is pushed, I'll add a note to JDK-8193639 [1] so anyone > working on it will know to undo the change in Platform.java. > > [1] https://bugs.openjdk.java.net/browse/JDK-8193639 > > thanks, > > Chris From igor.ignatyev at oracle.com Mon Apr 6 20:38:50 2020 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Mon, 6 Apr 2020 13:38:50 -0700 Subject: RFR(XS) 8242168: ClhsdbFindPC.java failed due to "RuntimeException: 'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr" In-Reply-To: <94496cf9-61fa-103b-e2f8-3d1f6d36bdda@oracle.com> References: <94496cf9-61fa-103b-e2f8-3d1f6d36bdda@oracle.com> Message-ID: <9606A20B-9CA4-413B-98EA-6265BD7B9453@oracle.com> LGTM ? Igor > On Apr 5, 2020, at 11:49 PM, Chris Plummer wrote: > > ?[Sorry about the resend. Subject wasn't quite right the first time.] > > Hello, > > Please help review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242168 > http://cr.openjdk.java.net/~cjplummer/8242168/webrev.00/ > > ClhsdbFindPC needs to be disabled when using -XX:+DeoptimizeALot because it means the expected compiled frame may not be compiled. I also fixed ClhsdbJstackXcompStress since it also relies on frames being compiled, although I never got it to fail since it managed to always find at least one compiled frame. > > I confirmed that with this fix these two tests are not run when -XX:+DeoptimizeALot is used. If not used, behavior is unchanged. ClhsdbFindPC.java#id0 runs whether or not using -Xcomp and #id1 still only runs when not using -Xcomp. ClhsdbJstackXcompStress gets run whether or not -Xcomp is used. > > thanks, > > Chris From chris.plummer at oracle.com Mon Apr 6 21:08:11 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Apr 2020 14:08:11 -0700 Subject: RFR(S) 8242235: Disable SA testing on Solaris. Remove JDK-8193639 entries from ProblemList.txt In-Reply-To: <28a65798-b46e-d482-4ece-09906d0ada78@oracle.com> References: <213cbe04-beb1-bc55-a34e-14789426a294@oracle.com> <28a65798-b46e-d482-4ece-09906d0ada78@oracle.com> Message-ID: <7782696d-c456-20a8-f70a-7376300e6498@oracle.com> On 4/6/20 1:21 PM, Daniel D. Daugherty wrote: > On 4/6/20 4:10 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8242235 >> http://cr.openjdk.java.net/~cjplummer/8242235/webrev.00 > > test/hotspot/jtreg/ProblemList.txt > ??? No comments. > > test/jdk/ProblemList.txt > ??? No comments. > > test/lib/jdk/test/lib/Platform.java > ??? No comments. > > Thumbs up. > > In the bug report, you said: > >> although due to test renames, moves, and additions, there are actually >> still about 8 tests running on Solaris, but they shouldn't be. > > Perhaps those 8 tests are not affected by the bug that causes > JDK-8193639. > I don't see any recent links to JDK-8193639 that are valid failures. > There are some links to JDK-8193639 for non-Solaris platforms which means > those links are wrong, but none for Solaris (that I see). Hi Dan, Thanks for the review. On closer look it's more like 3 tests since 5 of the 8 don't really count. One was a new test I wrote that I haven't pushed yet (and didn't problem list because I wanted to do this CR first). Two are tests that are not run for other reasons (but are also incorrectly problem listed for 8193639). Two are tests that only recently started running on solaris due to splitting out into #id0 and #id1 runs, so the problem list is not properly filtering them. So maybe 3 tests have been running for a while without causing issues, but I honestly don't think it's worth the effort to figure out which tests are truly affected by JDK-8193639, and try to make the problem list correct to allow them to run. thanks, Chris > > Dan > > >> >> The SA problem list entries due to JDK-8193639 [1] have been a burden >> to maintain, and are badly out of date. Easiest solution is to remove >> them and disable SA testing on Solaris, which is what all the entries >> were suppose to be doing in the first place (although not always >> correctly). >> >> Once this change is pushed, I'll add a note to JDK-8193639 [1] so >> anyone working on it will know to undo the change in Platform.java. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8193639 >> >> thanks, >> >> Chris > From daniel.daugherty at oracle.com Mon Apr 6 21:17:46 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Apr 2020 17:17:46 -0400 Subject: RFR(S) 8242235: Disable SA testing on Solaris. Remove JDK-8193639 entries from ProblemList.txt In-Reply-To: <7782696d-c456-20a8-f70a-7376300e6498@oracle.com> References: <213cbe04-beb1-bc55-a34e-14789426a294@oracle.com> <28a65798-b46e-d482-4ece-09906d0ada78@oracle.com> <7782696d-c456-20a8-f70a-7376300e6498@oracle.com> Message-ID: <28b2f8ac-6c5e-dcf9-eef6-9a35cdbc2055@oracle.com> On 4/6/20 5:08 PM, Chris Plummer wrote: > On 4/6/20 1:21 PM, Daniel D. Daugherty wrote: >> On 4/6/20 4:10 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8242235 >>> http://cr.openjdk.java.net/~cjplummer/8242235/webrev.00 >> >> test/hotspot/jtreg/ProblemList.txt >> ??? No comments. >> >> test/jdk/ProblemList.txt >> ??? No comments. >> >> test/lib/jdk/test/lib/Platform.java >> ??? No comments. >> >> Thumbs up. >> >> In the bug report, you said: >> >>> although due to test renames, moves, and additions, there are actually >>> still about 8 tests running on Solaris, but they shouldn't be. >> >> Perhaps those 8 tests are not affected by the bug that causes >> JDK-8193639. >> I don't see any recent links to JDK-8193639 that are valid failures. >> There are some links to JDK-8193639 for non-Solaris platforms which >> means >> those links are wrong, but none for Solaris (that I see). > Hi Dan, > > Thanks for the review. > > On closer look it's more like 3 tests since 5 of the 8 don't really > count. One was a new test I wrote that I haven't pushed yet (and > didn't problem list because I wanted to do this CR first). Two are > tests that are not run for other reasons (but are also incorrectly > problem listed for 8193639). Two are tests that only recently started > running on solaris due to splitting out into #id0 and #id1 runs, so > the problem list is not properly filtering them. > > So maybe 3 tests have been running for a while without causing issues, > but I honestly don't think it's worth the effort to figure out which > tests are truly affected by JDK-8193639, and try to make the problem > list correct to allow them to run. No problem. Your call on what to do here. Dan > > thanks, > > Chris > >> >> Dan >> >> >>> >>> The SA problem list entries due to JDK-8193639 [1] have been a >>> burden to maintain, and are badly out of date. Easiest solution is >>> to remove them and disable SA testing on Solaris, which is what all >>> the entries were suppose to be doing in the first place (although >>> not always correctly). >>> >>> Once this change is pushed, I'll add a note to JDK-8193639 [1] so >>> anyone working on it will know to undo the change in Platform.java. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8193639 >>> >>> thanks, >>> >>> Chris >> > > From chris.plummer at oracle.com Mon Apr 6 23:57:17 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Apr 2020 16:57:17 -0700 Subject: RFR(XS) 8242168: ClhsdbFindPC.java failed due to "RuntimeException: 'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr" In-Reply-To: <9606A20B-9CA4-413B-98EA-6265BD7B9453@oracle.com> References: <94496cf9-61fa-103b-e2f8-3d1f6d36bdda@oracle.com> <9606A20B-9CA4-413B-98EA-6265BD7B9453@oracle.com> Message-ID: Thanks Igor and Leonid! Chris On 4/6/20 1:38 PM, Igor Ignatev wrote: > LGTM > > ? Igor > >> On Apr 5, 2020, at 11:49 PM, Chris Plummer wrote: >> >> ?[Sorry about the resend. Subject wasn't quite right the first time.] >> >> Hello, >> >> Please help review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8242168 >> http://cr.openjdk.java.net/~cjplummer/8242168/webrev.00/ >> >> ClhsdbFindPC needs to be disabled when using -XX:+DeoptimizeALot because it means the expected compiled frame may not be compiled. I also fixed ClhsdbJstackXcompStress since it also relies on frames being compiled, although I never got it to fail since it managed to always find at least one compiled frame. >> >> I confirmed that with this fix these two tests are not run when -XX:+DeoptimizeALot is used. If not used, behavior is unchanged. ClhsdbFindPC.java#id0 runs whether or not using -Xcomp and #id1 still only runs when not using -Xcomp. ClhsdbJstackXcompStress gets run whether or not -Xcomp is used. >> >> thanks, >> >> Chris From chris.plummer at oracle.com Tue Apr 7 00:07:51 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Apr 2020 17:07:51 -0700 Subject: RFR(S) 8242142: convert clhsdb "class" and "classes" commands from javascript to java In-Reply-To: <017c1519-a238-ebf5-277c-9a8e7d53d7ba@oracle.com> References: <68751dbe-7c4d-f6ca-ca4f-652a15daa57e@oracle.com> <42060553-4053-be92-1b79-3c7d3dd2c5f8@oracle.com> <33fa6271-1de5-9233-5d45-62f4dfd2b369@oracle.com> <017c1519-a238-ebf5-277c-9a8e7d53d7ba@oracle.com> Message-ID: <12aa6c7e-f834-d330-93d1-3b6e0234aa9c@oracle.com> Can I get one more review please? thanks, Chris On 4/3/20 6:56 PM, Chris Plummer wrote: > Here's an updated webrev. I also renamed APP_CLASSNAME to > APP_SLASH_CLASSNAME just to make it a bit more clear which format is > being used. > > http://cr.openjdk.java.net/~cjplummer/8242142/webrev.01 > > thanks, > > Chris > > On 4/3/20 6:13 PM, Chris Plummer wrote: >> Ok, I'll make those changes. Thanks for the review. >> >> Chris >> >> On 4/3/20 5:44 PM, Alex Menkov wrote: >>> Hi Chris, >>> >>> The fix looks good. >>> Couple minor notes about the test: >>> >>> ?41???? static final String APP_CLASSNAME = >>> "jdk/test/lib/apps/LingeredApp"; >>> ? 42???? static final String APP_DOT_CLASSNAME = >>> APP_CLASSNAME.replace('/', '.'); >>> >>> I'd make this >>> static final String APP_DOT_CLASSNAME = LingeredApp.class.getName(); >>> static final String APP_CLASSNAME = APP_DOT_CLASSNAME.replace('.', >>> '/'); >>> >>> >>> >>> ?52???????????? theApp = new LingeredApp(); >>> ?53???????????? LingeredApp.startApp(theApp); >>> >>> can be just >>> >>> theApp = LingeredApp.startApp(); >>> >>> --alex >>> >>> On 04/03/2020 15:08, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8242142 >>>> http://cr.openjdk.java.net/~cjplummer/8242142/webrev.00/ >>>> >>>> See the CR for details. Note the output for the "class" command >>>> looks like: >>>> >>>> ???? jdk/test/lib/apps/LingeredApp @0x0000000800bcb040 >>>> >>>> The output for "classes" is the same, except each class is listed. >>>> The output for "print " is kind of long, but includes >>>> the following line, which the test looks for to verify the "class" >>>> output. >>>> >>>> ???? public class jdk.test.lib.apps.LingeredApp @0x0000000800bcb040 >>>> >>>> thanks, >>>> >>>> Chris >>>> >> >> > > From serguei.spitsyn at oracle.com Tue Apr 7 01:02:26 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Apr 2020 18:02:26 -0700 Subject: RFR(S) 8242142: convert clhsdb "class" and "classes" commands from javascript to java In-Reply-To: <12aa6c7e-f834-d330-93d1-3b6e0234aa9c@oracle.com> References: <68751dbe-7c4d-f6ca-ca4f-652a15daa57e@oracle.com> <42060553-4053-be92-1b79-3c7d3dd2c5f8@oracle.com> <33fa6271-1de5-9233-5d45-62f4dfd2b369@oracle.com> <017c1519-a238-ebf5-277c-9a8e7d53d7ba@oracle.com> <12aa6c7e-f834-d330-93d1-3b6e0234aa9c@oracle.com> Message-ID: <4b2793a9-06d6-3d9c-e885-9bad802f7fcb@oracle.com> Hi Chris, This looks good. Thanks, Serguei On 4/6/20 17:07, Chris Plummer wrote: > Can I get one more review please? > > thanks, > > Chris > > On 4/3/20 6:56 PM, Chris Plummer wrote: >> Here's an updated webrev. I also renamed APP_CLASSNAME to >> APP_SLASH_CLASSNAME just to make it a bit more clear which format is >> being used. >> >> http://cr.openjdk.java.net/~cjplummer/8242142/webrev.01 >> >> thanks, >> >> Chris >> >> On 4/3/20 6:13 PM, Chris Plummer wrote: >>> Ok, I'll make those changes. Thanks for the review. >>> >>> Chris >>> >>> On 4/3/20 5:44 PM, Alex Menkov wrote: >>>> Hi Chris, >>>> >>>> The fix looks good. >>>> Couple minor notes about the test: >>>> >>>> ?41???? static final String APP_CLASSNAME = >>>> "jdk/test/lib/apps/LingeredApp"; >>>> ? 42???? static final String APP_DOT_CLASSNAME = >>>> APP_CLASSNAME.replace('/', '.'); >>>> >>>> I'd make this >>>> static final String APP_DOT_CLASSNAME = LingeredApp.class.getName(); >>>> static final String APP_CLASSNAME = APP_DOT_CLASSNAME.replace('.', >>>> '/'); >>>> >>>> >>>> >>>> ?52???????????? theApp = new LingeredApp(); >>>> ?53???????????? LingeredApp.startApp(theApp); >>>> >>>> can be just >>>> >>>> theApp = LingeredApp.startApp(); >>>> >>>> --alex >>>> >>>> On 04/03/2020 15:08, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8242142 >>>>> http://cr.openjdk.java.net/~cjplummer/8242142/webrev.00/ >>>>> >>>>> See the CR for details. Note the output for the "class" command >>>>> looks like: >>>>> >>>>> ???? jdk/test/lib/apps/LingeredApp @0x0000000800bcb040 >>>>> >>>>> The output for "classes" is the same, except each class is listed. >>>>> The output for "print " is kind of long, but includes >>>>> the following line, which the test looks for to verify the "class" >>>>> output. >>>>> >>>>> ???? public class jdk.test.lib.apps.LingeredApp @0x0000000800bcb040 >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>> >>> >> >> > > From serguei.spitsyn at oracle.com Tue Apr 7 01:31:51 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Apr 2020 18:31:51 -0700 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> Message-ID: <5b8dfe15-63d7-0d31-70da-a7da383e1834@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Apr 7 01:51:39 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Apr 2020 18:51:39 -0700 Subject: RFR(S) 8242142: convert clhsdb "class" and "classes" commands from javascript to java In-Reply-To: <4b2793a9-06d6-3d9c-e885-9bad802f7fcb@oracle.com> References: <68751dbe-7c4d-f6ca-ca4f-652a15daa57e@oracle.com> <42060553-4053-be92-1b79-3c7d3dd2c5f8@oracle.com> <33fa6271-1de5-9233-5d45-62f4dfd2b369@oracle.com> <017c1519-a238-ebf5-277c-9a8e7d53d7ba@oracle.com> <12aa6c7e-f834-d330-93d1-3b6e0234aa9c@oracle.com> <4b2793a9-06d6-3d9c-e885-9bad802f7fcb@oracle.com> Message-ID: <7b7e4b46-6345-f68f-da61-fe943b3ee17c@oracle.com> Thank you Serguei! Chris On 4/6/20 6:02 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > This looks good. > > Thanks, > Serguei > > > > On 4/6/20 17:07, Chris Plummer wrote: >> Can I get one more review please? >> >> thanks, >> >> Chris >> >> On 4/3/20 6:56 PM, Chris Plummer wrote: >>> Here's an updated webrev. I also renamed APP_CLASSNAME to >>> APP_SLASH_CLASSNAME just to make it a bit more clear which format is >>> being used. >>> >>> http://cr.openjdk.java.net/~cjplummer/8242142/webrev.01 >>> >>> thanks, >>> >>> Chris >>> >>> On 4/3/20 6:13 PM, Chris Plummer wrote: >>>> Ok, I'll make those changes. Thanks for the review. >>>> >>>> Chris >>>> >>>> On 4/3/20 5:44 PM, Alex Menkov wrote: >>>>> Hi Chris, >>>>> >>>>> The fix looks good. >>>>> Couple minor notes about the test: >>>>> >>>>> ?41???? static final String APP_CLASSNAME = >>>>> "jdk/test/lib/apps/LingeredApp"; >>>>> ? 42???? static final String APP_DOT_CLASSNAME = >>>>> APP_CLASSNAME.replace('/', '.'); >>>>> >>>>> I'd make this >>>>> static final String APP_DOT_CLASSNAME = LingeredApp.class.getName(); >>>>> static final String APP_CLASSNAME = APP_DOT_CLASSNAME.replace('.', >>>>> '/'); >>>>> >>>>> >>>>> >>>>> ?52???????????? theApp = new LingeredApp(); >>>>> ?53???????????? LingeredApp.startApp(theApp); >>>>> >>>>> can be just >>>>> >>>>> theApp = LingeredApp.startApp(); >>>>> >>>>> --alex >>>>> >>>>> On 04/03/2020 15:08, Chris Plummer wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8242142 >>>>>> http://cr.openjdk.java.net/~cjplummer/8242142/webrev.00/ >>>>>> >>>>>> See the CR for details. Note the output for the "class" command >>>>>> looks like: >>>>>> >>>>>> ???? jdk/test/lib/apps/LingeredApp @0x0000000800bcb040 >>>>>> >>>>>> The output for "classes" is the same, except each class is >>>>>> listed. The output for "print " is kind of long, but >>>>>> includes the following line, which the test looks for to verify >>>>>> the "class" output. >>>>>> >>>>>> ???? public class jdk.test.lib.apps.LingeredApp @0x0000000800bcb040 >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>> >>>> >>> >>> >> >> > From chris.plummer at oracle.com Tue Apr 7 01:54:23 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Apr 2020 18:54:23 -0700 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: <5b8dfe15-63d7-0d31-70da-a7da383e1834@oracle.com> References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> <5b8dfe15-63d7-0d31-70da-a7da383e1834@oracle.com> Message-ID: <775f3cf1-4d8a-0792-2194-a85a51efc58d@oracle.com> It's not a test. It a subclassed LingeredApp with code added to print all the system properties. But in any case I'm going to remove the problem listing in this webrev since I will push https://bugs.openjdk.java.net/browse/JDK-8242235 first, which gets rid of the need to problem list on solaris. Chris On 4/6/20 6:31 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > Quick question: > Should theserviceability/sa/LingeredAppSysProps.java be also problem > listed? > > Thanks, > Serguei > > > On 4/5/20 22:49, Chris Plummer wrote: >> Hello, >> >> Please help review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8242165 >> http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 >> >> Please see the CR for an explanation of the bug and the fix. If you >> need some help with the SA code, let me know and I'll provide some >> details. It was pretty much all new to me, so I tried to put the >> needed details in the CR. >> >> For the test, I compare the list of properties dumped using 3 >> different methods to make sure the same set is dumped for each: >> >> 1. jhsdb jinfo --sysprops >> 2. jinfo -sysprops >> 3. Simple app (LingeredAppSysProps) that calls >> System.getProperties().list(System.out) >> >> The app output is considered the master list that is compared against >> the others, and I also make sure each list has the same number of >> properties. >> >> thanks, >> >> Chris > From serguei.spitsyn at oracle.com Tue Apr 7 03:12:45 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Apr 2020 20:12:45 -0700 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: <775f3cf1-4d8a-0792-2194-a85a51efc58d@oracle.com> References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> <5b8dfe15-63d7-0d31-70da-a7da383e1834@oracle.com> <775f3cf1-4d8a-0792-2194-a85a51efc58d@oracle.com> Message-ID: <79c25309-5507-fb62-b383-d785cf06d74a@oracle.com> Okay, thanks! Serguei On 4/6/20 18:54, Chris Plummer wrote: > It's not a test. It a subclassed LingeredApp with code added to print > all the system properties. But in any case I'm going to remove the > problem listing in this webrev since I will push > https://bugs.openjdk.java.net/browse/JDK-8242235 first, which gets rid > of the need to problem list on solaris. > > Chris > > On 4/6/20 6:31 PM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> Quick question: >> Should theserviceability/sa/LingeredAppSysProps.java be also problem >> listed? >> >> Thanks, >> Serguei >> >> >> On 4/5/20 22:49, Chris Plummer wrote: >>> Hello, >>> >>> Please help review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8242165 >>> http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 >>> >>> Please see the CR for an explanation of the bug and the fix. If you >>> need some help with the SA code, let me know and I'll provide some >>> details. It was pretty much all new to me, so I tried to put the >>> needed details in the CR. >>> >>> For the test, I compare the list of properties dumped using 3 >>> different methods to make sure the same set is dumped for each: >>> >>> 1. jhsdb jinfo --sysprops >>> 2. jinfo -sysprops >>> 3. Simple app (LingeredAppSysProps) that calls >>> System.getProperties().list(System.out) >>> >>> The app output is considered the master list that is compared >>> against the others, and I also make sure each list has the same >>> number of properties. >>> >>> thanks, >>> >>> Chris >> > From serguei.spitsyn at oracle.com Tue Apr 7 07:00:52 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Apr 2020 00:00:52 -0700 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> Message-ID: <712f0cba-211d-47a4-ca8d-e96c61a146c0@oracle.com> Hi Chris, It looks good in general. But a couple of comments. http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03/test/hotspot/jtreg/serviceability/sa/TestSysProps.java.html I'm thinking if it'd make sense to do this kind of refactoring: ??? OutputAnalyzer runSACommand(String cmd, String argsStr, long pid) throws Exception { ??????? JDKToolLauncher launcher = JDKToolLauncher.createUsingTestJDK(cmd); ??????? for (String arg : argsStr.split(" ")) { ??????????? launcher.addToolArg(arg); ??????? } ??????? launcher.addToolArg(Long.toString(pid)); ??????? ProcessBuilder pb = SATestUtils.createProcessBuilder(launcher); ??????? System.out.println("> " + ProcessTools.getCommandLine(pb)); ??????? Process process = pb.start(); ??????? OutputAnalyzer out = new OutputAnalyzer(process); ??????? process.waitFor(); ??????? System.out.println(out.getStdout()); ??????? System.err.println(out.getStderr()); ??????? return out; ??? } ??? OutputAnalyzer jhsdbOut = runSACommand("jhsdb", "jinfo --sysprops --pid", app.getPid()); ??? OutputAnalyzer jinfoOut = runSACommand("jinfo", "-sysprops", app.getPid()); ??? jhsdbOut.shouldMatch("Debugger attached successfully."); ??? jinfoOut.shouldMatch("Java System Properties:"); Even though it does not seem to give a big advantage for this particular test it creates a useful pattern that can be replicated later if similar tests are needed in the future. Also, I wonder if the code at lines 158-178 is really needed. We should get a RuntimeException if any of the properties is not found in the jhsdb or jinfo output. So, the number of printed options should match. But maybe I'm missing something. Thanks, Serguei On 4/5/20 22:49, Chris Plummer wrote: > Hello, > > Please help review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242165 > http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 > > Please see the CR for an explanation of the bug and the fix. If you > need some help with the SA code, let me know and I'll provide some > details. It was pretty much all new to me, so I tried to put the > needed details in the CR. > > For the test, I compare the list of properties dumped using 3 > different methods to make sure the same set is dumped for each: > > 1. jhsdb jinfo --sysprops > 2. jinfo -sysprops > 3. Simple app (LingeredAppSysProps) that calls > System.getProperties().list(System.out) > > The app output is considered the master list that is compared against > the others, and I also make sure each list has the same number of > properties. > > thanks, > > Chris From chris.plummer at oracle.com Tue Apr 7 07:17:00 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 7 Apr 2020 00:17:00 -0700 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: <712f0cba-211d-47a4-ca8d-e96c61a146c0@oracle.com> References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> <712f0cba-211d-47a4-ca8d-e96c61a146c0@oracle.com> Message-ID: <7d8e3b68-a067-fb30-6a9d-fa95f1a579c6@oracle.com> Hi Serguei, Thanks for the review. I considered a refactoring like that. However, I'm going to expand this test when I push my fix to add support for the clhsdb "sysprops" commands (one of the clhsdb commands that was lost when we lost JS support). So I'll be executing that command also in this test, and doing so using the existing ClhsdbLauncher support, which means not directly using JDKToolLauncher. So it kind of seems odd to have 4 ways of producing the properties list, but only two of them use this shared code. However, when I add the clhsdb sysprops support, I'll see if some refactoring makes sense. Maybe I could maintain the context of each of the 3 tools that are run in separate class instances, and possibly some of the implementation of a run() method could look like when you envisioned. I think it's best to I see the code for all 3 ways of generating the properties before doing that. As for the check on the number of properties found, my concern was having properties in one of two jinfo lists that are not in the output of LingeredAppSysProps. So at first I was thinking I would need to use each list as a primary list and have it compare against the other two, but then I realized I could just use the count of the number of properties found as a sanity check. thanks, Chris On 4/7/20 12:00 AM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > It looks good in general. > But a couple of comments. > > http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03/test/hotspot/jtreg/serviceability/sa/TestSysProps.java.html > > > I'm thinking if it'd make sense to do this kind of refactoring: > > ??? OutputAnalyzer runSACommand(String cmd, String argsStr, long pid) > throws Exception { > ??????? JDKToolLauncher launcher = > JDKToolLauncher.createUsingTestJDK(cmd); > > ??????? for (String arg : argsStr.split(" ")) { > ??????????? launcher.addToolArg(arg); > ??????? } > ??????? launcher.addToolArg(Long.toString(pid)); > ??????? ProcessBuilder pb = SATestUtils.createProcessBuilder(launcher); > ??????? System.out.println("> " + ProcessTools.getCommandLine(pb)); > ??????? Process process = pb.start(); > ??????? OutputAnalyzer out = new OutputAnalyzer(process); > > ??????? process.waitFor(); > > ??????? System.out.println(out.getStdout()); > ??????? System.err.println(out.getStderr()); > ??????? return out; > ??? } > > ??? OutputAnalyzer jhsdbOut = runSACommand("jhsdb", "jinfo --sysprops > --pid", app.getPid()); > ??? OutputAnalyzer jinfoOut = runSACommand("jinfo", "-sysprops", > app.getPid()); > > ??? jhsdbOut.shouldMatch("Debugger attached successfully."); > ??? jinfoOut.shouldMatch("Java System Properties:"); > > Even though it does not seem to give a big advantage for this > particular test it creates a useful pattern that can be replicated > later if similar tests are needed in the future. > > > Also, I wonder if the code at lines 158-178 is really needed. > We should get a RuntimeException if any of the properties is not found > in the jhsdb or jinfo output. > So, the number of printed options should match. > But maybe I'm missing something. > > Thanks, > Serguei > > > > On 4/5/20 22:49, Chris Plummer wrote: >> Hello, >> >> Please help review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8242165 >> http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 >> >> Please see the CR for an explanation of the bug and the fix. If you >> need some help with the SA code, let me know and I'll provide some >> details. It was pretty much all new to me, so I tried to put the >> needed details in the CR. >> >> For the test, I compare the list of properties dumped using 3 >> different methods to make sure the same set is dumped for each: >> >> 1. jhsdb jinfo --sysprops >> 2. jinfo -sysprops >> 3. Simple app (LingeredAppSysProps) that calls >> System.getProperties().list(System.out) >> >> The app output is considered the master list that is compared against >> the others, and I also make sure each list has the same number of >> properties. >> >> thanks, >> >> Chris > From serguei.spitsyn at oracle.com Tue Apr 7 07:35:25 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Apr 2020 00:35:25 -0700 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: <7d8e3b68-a067-fb30-6a9d-fa95f1a579c6@oracle.com> References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> <712f0cba-211d-47a4-ca8d-e96c61a146c0@oracle.com> <7d8e3b68-a067-fb30-6a9d-fa95f1a579c6@oracle.com> Message-ID: <18c9f262-f2fb-3eb3-a68d-e4407a81289a@oracle.com> Hi Chris, I'm okay with your approaches. Please, consider it reviewed. Thanks, Serguei On 4/7/20 00:17, Chris Plummer wrote: > Hi Serguei, > > Thanks for the review. I considered a refactoring like that. However, > I'm going to expand this test when I push my fix to add support for > the clhsdb "sysprops" commands (one of the clhsdb commands that was > lost when we lost JS support). So I'll be executing that command also > in this test, and doing so using the existing ClhsdbLauncher support, > which means not directly using JDKToolLauncher. So it kind of seems > odd to have 4 ways of producing the properties list, but only two of > them use this shared code. However, when I add the clhsdb sysprops > support, I'll see if some refactoring makes sense. Maybe I could > maintain the context of each of the 3 tools that are run in separate > class instances, and possibly some of the implementation of a run() > method could look like when you envisioned. I think it's best to I see > the code for all 3 ways of generating the properties before doing that. > > As for the check on the number of properties found, my concern was > having properties in one of two jinfo lists that are not in the output > of LingeredAppSysProps. So at first I was thinking I would need to use > each list as a primary list and have it compare against the other two, > but then I realized I could just use the count of the number of > properties found as a sanity check. > > thanks, > > Chris > > On 4/7/20 12:00 AM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> It looks good in general. >> But a couple of comments. >> >> http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03/test/hotspot/jtreg/serviceability/sa/TestSysProps.java.html >> >> >> I'm thinking if it'd make sense to do this kind of refactoring: >> >> ??? OutputAnalyzer runSACommand(String cmd, String argsStr, long pid) >> throws Exception { >> ??????? JDKToolLauncher launcher = >> JDKToolLauncher.createUsingTestJDK(cmd); >> >> ??????? for (String arg : argsStr.split(" ")) { >> ??????????? launcher.addToolArg(arg); >> ??????? } >> ??????? launcher.addToolArg(Long.toString(pid)); >> ??????? ProcessBuilder pb = SATestUtils.createProcessBuilder(launcher); >> ??????? System.out.println("> " + ProcessTools.getCommandLine(pb)); >> ??????? Process process = pb.start(); >> ??????? OutputAnalyzer out = new OutputAnalyzer(process); >> >> ??????? process.waitFor(); >> >> ??????? System.out.println(out.getStdout()); >> ??????? System.err.println(out.getStderr()); >> ??????? return out; >> ??? } >> >> ??? OutputAnalyzer jhsdbOut = runSACommand("jhsdb", "jinfo --sysprops >> --pid", app.getPid()); >> ??? OutputAnalyzer jinfoOut = runSACommand("jinfo", "-sysprops", >> app.getPid()); >> >> ??? jhsdbOut.shouldMatch("Debugger attached successfully."); >> ??? jinfoOut.shouldMatch("Java System Properties:"); >> >> Even though it does not seem to give a big advantage for this >> particular test it creates a useful pattern that can be replicated >> later if similar tests are needed in the future. >> >> >> Also, I wonder if the code at lines 158-178 is really needed. >> We should get a RuntimeException if any of the properties is not >> found in the jhsdb or jinfo output. >> So, the number of printed options should match. >> But maybe I'm missing something. >> >> Thanks, >> Serguei >> >> >> >> On 4/5/20 22:49, Chris Plummer wrote: >>> Hello, >>> >>> Please help review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8242165 >>> http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 >>> >>> Please see the CR for an explanation of the bug and the fix. If you >>> need some help with the SA code, let me know and I'll provide some >>> details. It was pretty much all new to me, so I tried to put the >>> needed details in the CR. >>> >>> For the test, I compare the list of properties dumped using 3 >>> different methods to make sure the same set is dumped for each: >>> >>> 1. jhsdb jinfo --sysprops >>> 2. jinfo -sysprops >>> 3. Simple app (LingeredAppSysProps) that calls >>> System.getProperties().list(System.out) >>> >>> The app output is considered the master list that is compared >>> against the others, and I also make sure each list has the same >>> number of properties. >>> >>> thanks, >>> >>> Chris >> > > From chris.plummer at oracle.com Tue Apr 7 21:16:44 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 7 Apr 2020 14:16:44 -0700 Subject: RFR(M) 8242165: SA sysprops support fails to dump all system properties In-Reply-To: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> References: <650c6c87-f1b6-4103-551e-6a97ff411970@oracle.com> Message-ID: Since JDK-8193639 has now been pushed, this test no longer needs to be problem listed on solaris, so I undid that change to ProblemList.txt. However, it does fail on with ZGC due to JDK-8220624, so it is now problem listed in ProblemList-zgc.txt. I also fixed a minor sort order in the problem list: diff --git a/test/hotspot/jtreg/ProblemList-zgc.txt b/test/hotspot/jtreg/ProblemList-zgc.txt --- a/test/hotspot/jtreg/ProblemList-zgc.txt +++ b/test/hotspot/jtreg/ProblemList-zgc.txt @@ -28,8 +28,9 @@ ?############################################################################# ?resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java 8220624?? generic-all +serviceability/sa/CDSJMapClstats.java 8220624?? generic-all +serviceability/sa/ClhsdClasses.java 8220624?? generic-all ?serviceability/sa/ClhsdbDumpheap.java 8220624?? generic-all -serviceability/sa/CDSJMapClstats.java 8220624?? generic-all ?serviceability/sa/ClhsdbCDSJstackPrintAll.java 8220624?? generic-all ?serviceability/sa/ClhsdbFindPC.java#id0 8220624?? generic-all ?serviceability/sa/ClhsdbFindPC.java#id1 8220624?? generic-all thanks, Chris On 4/5/20 10:49 PM, Chris Plummer wrote: > Hello, > > Please help review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242165 > http://cr.openjdk.java.net/~cjplummer/8242165/webrev.03 > > Please see the CR for an explanation of the bug and the fix. If you > need some help with the SA code, let me know and I'll provide some > details. It was pretty much all new to me, so I tried to put the > needed details in the CR. > > For the test, I compare the list of properties dumped using 3 > different methods to make sure the same set is dumped for each: > > 1. jhsdb jinfo --sysprops > 2. jinfo -sysprops > 3. Simple app (LingeredAppSysProps) that calls > System.getProperties().list(System.out) > > The app output is considered the master list that is compared against > the others, and I also make sure each list has the same number of > properties. > > thanks, > > Chris From leonid.mesnik at oracle.com Tue Apr 7 21:46:02 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 7 Apr 2020 14:46:02 -0700 Subject: RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean Message-ID: <023FE036-4A9F-4E3B-B231-EEC06EA008C6@oracle.com> Hi Could you please review following fix which just moves content of ThreadMBean back into ThreadMXBean. webrev: http://cr.openjdk.java.net/~lmesnik/8242295/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8242295 -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Apr 7 22:00:00 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 7 Apr 2020 15:00:00 -0700 Subject: RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean In-Reply-To: <023FE036-4A9F-4E3B-B231-EEC06EA008C6@oracle.com> References: <023FE036-4A9F-4E3B-B231-EEC06EA008C6@oracle.com> Message-ID: <15ED9DD2-0448-433A-B5CA-0D8B479E2BD4@oracle.com> Hi Leonid, looks good and trivial to me. one question, will it also make sense to replace ThreadMBean w/ ThreadMXBean in test descriptions, e.g. at L#33 of test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime001/TestDescription.java? Thanks, -- Igor > On Apr 7, 2020, at 2:46 PM, Leonid Mesnik wrote: > > Hi > Could you please review following fix which just moves content of ThreadMBean back into ThreadMXBean. > > webrev: http://cr.openjdk.java.net/~lmesnik/8242295/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8242295 -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 7 22:39:50 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Apr 2020 15:39:50 -0700 Subject: RFR (XS): 8242241: add assert to ClassUnloadEventImpl::className Message-ID: <6c66916f-ccdf-6d16-ae98-a20eea48b7fe@oracle.com> An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Tue Apr 7 22:56:04 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 7 Apr 2020 15:56:04 -0700 Subject: RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean In-Reply-To: <15ED9DD2-0448-433A-B5CA-0D8B479E2BD4@oracle.com> References: <023FE036-4A9F-4E3B-B231-EEC06EA008C6@oracle.com> <15ED9DD2-0448-433A-B5CA-0D8B479E2BD4@oracle.com> Message-ID: <40ea0303-7685-8552-2592-46d121a54bc0@oracle.com> Sure I've updated ThreadMBean to ThreadMXBean in test descriptions for ThreadMXBean tests . http://cr.openjdk.java.net/~lmesnik/8242295/webrev.01/ Leonid On 4/7/20 3:00 PM, Igor Ignatyev wrote: > Hi Leonid, > > looks good and trivial to me. one question, will it also make sense to > replace ThreadMBean w/ ThreadMXBean in test descriptions, e.g. at L#33 > of > test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime001/TestDescription.java? > > Thanks, > -- Igor > >> On Apr 7, 2020, at 2:46 PM, Leonid Mesnik > > wrote: >> >> Hi >> Could you please review following fix which just moves content >> of?ThreadMBean back into?ThreadMXBean. >> >> webrev: http://cr.openjdk.java.net/~lmesnik/8242295/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8242295 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Apr 7 23:06:24 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 7 Apr 2020 16:06:24 -0700 Subject: RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean In-Reply-To: <40ea0303-7685-8552-2592-46d121a54bc0@oracle.com> References: <023FE036-4A9F-4E3B-B231-EEC06EA008C6@oracle.com> <15ED9DD2-0448-433A-B5CA-0D8B479E2BD4@oracle.com> <40ea0303-7685-8552-2592-46d121a54bc0@oracle.com> Message-ID: great! what about nsk/monitoring/stress/thread/ ? they all have lines 'and states gotten via the ThreadMBean interface.' (strace010.java has 3 occurrences, other files just one) -- Igor > On Apr 7, 2020, at 3:56 PM, Leonid Mesnik wrote: > > Sure > > I've updated ThreadMBean to ThreadMXBean in test descriptions for ThreadMXBean tests . > > http://cr.openjdk.java.net/~lmesnik/8242295/webrev.01/ > Leonid > > On 4/7/20 3:00 PM, Igor Ignatyev wrote: >> Hi Leonid, >> >> looks good and trivial to me. one question, will it also make sense to replace ThreadMBean w/ ThreadMXBean in test descriptions, e.g. at L#33 of test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime001/TestDescription.java? >> >> Thanks, >> -- Igor >> >>> On Apr 7, 2020, at 2:46 PM, Leonid Mesnik > wrote: >>> >>> Hi >>> Could you please review following fix which just moves content of ThreadMBean back into ThreadMXBean. >>> >>> webrev: http://cr.openjdk.java.net/~lmesnik/8242295/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8242295 -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Tue Apr 7 23:26:50 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 7 Apr 2020 16:26:50 -0700 Subject: RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean In-Reply-To: References: <023FE036-4A9F-4E3B-B231-EEC06EA008C6@oracle.com> <15ED9DD2-0448-433A-B5CA-0D8B479E2BD4@oracle.com> <40ea0303-7685-8552-2592-46d121a54bc0@oracle.com> Message-ID: I didn't want to touch unrelated files and spread this fix outside vmTestbase/nsk/monitoring/ThreadMBean package. I wanted just to merge folders to don't confuse people by layout. The ThreadMBean is mentioned also in test/jdk/sun/management/jmxremote/bootstrap/ files and src/jdk.management.agent/share/conf/management.properties Also sometimes just MBean used to point to corresponding MXBean in comments. (Might it is a correct to use MBean there) So, let just change ThreadMBean in nsk/monitoring/stress/thread/ and stop updating comments on this. BTW, I will change summary to 8242295: Change ThreadMBean in vmTestbase/nsk/monitoring to ThreadMXBean to better describe changes Leonid On 4/7/20 4:06 PM, Igor Ignatyev wrote: > great! what about nsk/monitoring/stress/thread/ ? they all have lines > 'and states gotten via the?ThreadMBean?interface.' ?(strace010.java > has 3 occurrences, other files just one) > > -- Igor > >> On Apr 7, 2020, at 3:56 PM, Leonid Mesnik > > wrote: >> >> Sure >> >> I've updated ThreadMBean to ThreadMXBean in test descriptions for >> ThreadMXBean tests . >> >> http://cr.openjdk.java.net/~lmesnik/8242295/webrev.01/ >> >> Leonid >> >> On 4/7/20 3:00 PM, Igor Ignatyev wrote: >>> Hi Leonid, >>> >>> looks good and trivial to me. one question, will it also make sense >>> to replace ThreadMBean w/ ThreadMXBean in test descriptions, e.g. at >>> L#33 of >>> test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime001/TestDescription.java? >>> >>> Thanks, >>> -- Igor >>> >>>> On Apr 7, 2020, at 2:46 PM, Leonid Mesnik >>> > wrote: >>>> >>>> Hi >>>> Could you please review following fix which just moves content >>>> of?ThreadMBean back into?ThreadMXBean. >>>> >>>> webrev: http://cr.openjdk.java.net/~lmesnik/8242295/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8242295 >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Apr 7 23:31:11 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 7 Apr 2020 16:31:11 -0700 Subject: RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean In-Reply-To: References: <023FE036-4A9F-4E3B-B231-EEC06EA008C6@oracle.com> <15ED9DD2-0448-433A-B5CA-0D8B479E2BD4@oracle.com> <40ea0303-7685-8552-2592-46d121a54bc0@oracle.com> Message-ID: > On Apr 7, 2020, at 4:26 PM, Leonid Mesnik wrote: > > I didn't want to touch unrelated files and spread this fix outside vmTestbase/nsk/monitoring/ThreadMBean package. I wanted just to merge folders to don't confuse people by layout. > > The ThreadMBean is mentioned also in > > test/jdk/sun/management/jmxremote/bootstrap/ > > files and > > src/jdk.management.agent/share/conf/management.properties > > Also sometimes just MBean used to point to corresponding MXBean in comments. (Might it is a correct to use MBean there) > > So, let just change ThreadMBean in nsk/monitoring/stress/thread/ and stop updating comments on this. > sure, could you please file an RFE(RFEs) to update other places? -- Igor > BTW, I will change summary to > > 8242295: Change ThreadMBean in vmTestbase/nsk/monitoring to ThreadMXBean > > to better describe changes > > Leonid > > On 4/7/20 4:06 PM, Igor Ignatyev wrote: >> great! what about nsk/monitoring/stress/thread/ ? they all have lines 'and states gotten via the ThreadMBean interface.' (strace010.java has 3 occurrences, other files just one) >> >> -- Igor >> >>> On Apr 7, 2020, at 3:56 PM, Leonid Mesnik > wrote: >>> >>> Sure >>> >>> I've updated ThreadMBean to ThreadMXBean in test descriptions for ThreadMXBean tests . >>> >>> http://cr.openjdk.java.net/~lmesnik/8242295/webrev.01/ >>> Leonid >>> >>> On 4/7/20 3:00 PM, Igor Ignatyev wrote: >>>> Hi Leonid, >>>> >>>> looks good and trivial to me. one question, will it also make sense to replace ThreadMBean w/ ThreadMXBean in test descriptions, e.g. at L#33 of test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime001/TestDescription.java? >>>> >>>> Thanks, >>>> -- Igor >>>> >>>>> On Apr 7, 2020, at 2:46 PM, Leonid Mesnik > wrote: >>>>> >>>>> Hi >>>>> Could you please review following fix which just moves content of ThreadMBean back into ThreadMXBean. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~lmesnik/8242295/webrev.00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8242295 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Tue Apr 7 23:49:06 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 7 Apr 2020 16:49:06 -0700 Subject: RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean In-Reply-To: References: <023FE036-4A9F-4E3B-B231-EEC06EA008C6@oracle.com> <15ED9DD2-0448-433A-B5CA-0D8B479E2BD4@oracle.com> <40ea0303-7685-8552-2592-46d121a54bc0@oracle.com> Message-ID: <6fad299a-6353-6379-39ba-fee8bf27f1a4@oracle.com> Thank you for review. Filed https://bugs.openjdk.java.net/browse/JDK-8242328 Leonid On 4/7/20 4:31 PM, Igor Ignatyev wrote: > > >> On Apr 7, 2020, at 4:26 PM, Leonid Mesnik > > wrote: >> >> I didn't want to touch unrelated files and spread this fix outside >> vmTestbase/nsk/monitoring/ThreadMBean package. I wanted just to merge >> folders to don't confuse people by layout. >> >> The ThreadMBean is mentioned also in >> >> test/jdk/sun/management/jmxremote/bootstrap/ >> >> files and >> >> src/jdk.management.agent/share/conf/management.properties >> >> Also sometimes just MBean used to point to corresponding MXBean in >> comments. (Might it is a correct to use MBean there) >> >> So, let just change ThreadMBean in nsk/monitoring/stress/thread/ and >> stop updating comments on this. >> > sure, could you please file an RFE(RFEs) to update other places? > > -- Igor >> >> BTW, I will change summary to >> >> 8242295: Change ThreadMBean in vmTestbase/nsk/monitoring to ThreadMXBean >> >> to better describe changes >> > >> Leonid >> >> On 4/7/20 4:06 PM, Igor Ignatyev wrote: >>> great! what about nsk/monitoring/stress/thread/ ? they all have >>> lines 'and states gotten via the?ThreadMBean?interface.' >>> ?(strace010.java has 3 occurrences, other files just one) >>> >>> -- Igor >>> >>>> On Apr 7, 2020, at 3:56 PM, Leonid Mesnik >>> > wrote: >>>> >>>> Sure >>>> >>>> I've updated ThreadMBean to ThreadMXBean in test descriptions for >>>> ThreadMXBean tests . >>>> >>>> http://cr.openjdk.java.net/~lmesnik/8242295/webrev.01/ >>>> >>>> Leonid >>>> >>>> On 4/7/20 3:00 PM, Igor Ignatyev wrote: >>>>> Hi Leonid, >>>>> >>>>> looks good and trivial to me. one question, will it also make >>>>> sense to replace ThreadMBean w/ ThreadMXBean in test descriptions, >>>>> e.g. at L#33 of >>>>> test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime001/TestDescription.java? >>>>> >>>>> Thanks, >>>>> -- Igor >>>>> >>>>>> On Apr 7, 2020, at 2:46 PM, Leonid Mesnik >>>>>> > wrote: >>>>>> >>>>>> Hi >>>>>> Could you please review following fix which just moves content >>>>>> of?ThreadMBean back into?ThreadMXBean. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~lmesnik/8242295/webrev.00/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8242295 >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Apr 7 23:53:43 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 7 Apr 2020 16:53:43 -0700 Subject: RFR: 8242295: Move files from vmTestbase/nsk/monitoring/ThreadMBean into ThreadMXBean In-Reply-To: <6fad299a-6353-6379-39ba-fee8bf27f1a4@oracle.com> References: <023FE036-4A9F-4E3B-B231-EEC06EA008C6@oracle.com> <15ED9DD2-0448-433A-B5CA-0D8B479E2BD4@oracle.com> <40ea0303-7685-8552-2592-46d121a54bc0@oracle.com> <6fad299a-6353-6379-39ba-fee8bf27f1a4@oracle.com> Message-ID: <4C88C872-EFF5-4E72-9612-D1FC2ECE7A22@oracle.com> JFYI: I also remembered that I did file an RFE for this renaming -- https://bugs.openjdk.java.net/browse/JDK-8208245 . and as it seems that your patch addresses it fully, I'll close 8208245 as a dup of 8242295. -- Igor > On Apr 7, 2020, at 4:49 PM, Leonid Mesnik wrote: > > Thank you for review. > > Filed > > https://bugs.openjdk.java.net/browse/JDK-8242328 > Leonid > > On 4/7/20 4:31 PM, Igor Ignatyev wrote: >> >> >>> On Apr 7, 2020, at 4:26 PM, Leonid Mesnik > wrote: >>> >>> I didn't want to touch unrelated files and spread this fix outside vmTestbase/nsk/monitoring/ThreadMBean package. I wanted just to merge folders to don't confuse people by layout. >>> >>> The ThreadMBean is mentioned also in >>> >>> test/jdk/sun/management/jmxremote/bootstrap/ >>> >>> files and >>> >>> src/jdk.management.agent/share/conf/management.properties >>> >>> Also sometimes just MBean used to point to corresponding MXBean in comments. (Might it is a correct to use MBean there) >>> >>> So, let just change ThreadMBean in nsk/monitoring/stress/thread/ and stop updating comments on this. >>> >> sure, could you please file an RFE(RFEs) to update other places? >> >> -- Igor >>> BTW, I will change summary to >>> >>> 8242295: Change ThreadMBean in vmTestbase/nsk/monitoring to ThreadMXBean >>> >>> to better describe changes >>> >> >>> Leonid >>> >>> On 4/7/20 4:06 PM, Igor Ignatyev wrote: >>>> great! what about nsk/monitoring/stress/thread/ ? they all have lines 'and states gotten via the ThreadMBean interface.' (strace010.java has 3 occurrences, other files just one) >>>> >>>> -- Igor >>>> >>>>> On Apr 7, 2020, at 3:56 PM, Leonid Mesnik > wrote: >>>>> >>>>> Sure >>>>> >>>>> I've updated ThreadMBean to ThreadMXBean in test descriptions for ThreadMXBean tests . >>>>> >>>>> http://cr.openjdk.java.net/~lmesnik/8242295/webrev.01/ >>>>> Leonid >>>>> >>>>> On 4/7/20 3:00 PM, Igor Ignatyev wrote: >>>>>> Hi Leonid, >>>>>> >>>>>> looks good and trivial to me. one question, will it also make sense to replace ThreadMBean w/ ThreadMXBean in test descriptions, e.g. at L#33 of test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/isCurrentThreadCpuTimeSupported/curthcputime001/TestDescription.java? >>>>>> >>>>>> Thanks, >>>>>> -- Igor >>>>>> >>>>>>> On Apr 7, 2020, at 2:46 PM, Leonid Mesnik > wrote: >>>>>>> >>>>>>> Hi >>>>>>> Could you please review following fix which just moves content of ThreadMBean back into ThreadMXBean. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~lmesnik/8242295/webrev.00/ >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8242295 >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Apr 8 03:12:52 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 7 Apr 2020 20:12:52 -0700 Subject: RFR(M) 8240990: convert clhsdb "dumpclass" command from javascript to java Message-ID: <4c0c5c3e-4c6e-ac52-cb8a-8aed6592a2cb@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8240990 http://cr.openjdk.java.net/~cjplummer/8240990/webrev.00 The javascript code was just a few lines like other recent commands, but it had quite a bit of support on the java side in JSJavaScriptEngine.dumpClass(), which needed some massaging when moved to CommandProcessor.java. The CR contains the javascript and java code that was converted. thanks, Chris From chris.plummer at oracle.com Wed Apr 8 04:57:59 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 7 Apr 2020 21:57:59 -0700 Subject: RFR(XS) 8242265: serviceability/sa/ClhsdbScanOops.java fails due to bad @requires expression Message-ID: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8242265 diff --git a/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java b/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java --- a/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java +++ b/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java @@ -25,7 +25,7 @@ ? * @test ? * @bug 8192985 ? * @summary Test the clhsdb 'scanoops' command - * @requires vm.gc.ParallelGC + * @requires vm.gc.Parallel ? * @requires vm.hasSA ? * @library /test/lib ? * @run main/othervm/timeout=1200 ClhsdbScanOops UseParallelGC @@ -35,7 +35,7 @@ ? * @test ? * @bug 8192985 ? * @summary Test the clhsdb 'scanoops' command - * @requires vm.gc.SerialGC + * @requires vm.gc.Serial ? * @requires vm.hasSA ? * @library /test/lib ? * @run main/othervm/timeout=1200 ClhsdbScanOops UseSerialGC I tested by removing the tests from our problem list so now they are actually run (and would see the reported failure if not fixed). thanks, Chris From chris.plummer at oracle.com Wed Apr 8 05:15:46 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 7 Apr 2020 22:15:46 -0700 Subject: RFR(S) 8242162: convert clhsdb "sysprops" command from javascript to java Message-ID: <5f166f1c-c1b2-c042-5b23-94e8d5d6f33d@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8242162 http://cr.openjdk.java.net/~cjplummer/8242162/webrev.00 http://cr.openjdk.java.net/~cjplummer/8242162/webrev.01 Note there are two webrevs. You can skip the first if you want. It's the initial straight forward implementation. After that I did refactoring, so it might be easier if you looked at webrev.00 first without the refactoring, but I will be pushing webrev.01. [Serguei, regarding the refactoring you suggested, I didn't find it was worth doing for the execution of the commands since there are 4 of them, and they all have subtle differences that makes it hard to refactor in a productive way. I did refactor comparing the lists and counting the lists.] Regarding the change in LingeredAppSysProps.java, I ran into an issue when I added the clhsdb test. I was suddenly seeing an extra property. It was user.timezone. I did some research and found that user.timezone is kind of special. If not set on the command line it will not be created until someone calls TimeZone.getDefault(). What?s interesting is that when using the Attach API to get the sysprops (using jinfo or jcmd), the first time you do this you don?t get back user.timezone, but repeat the command and you do. Somehow the first time the command is executed it triggers the initialization of user.timezone, but only after the sysprops result was generated. So in the test LingeredAppSysProps.main() was printing the properties without use.name, and so was "jhsdb jinfo" and "jinfo". But the last "jinfo" command triggered the initialization of user.timezone, so it turned up in the subsequent run of "clhsdb sysprops", and thus the count in that list was one higher than the rest. By forcing the initialization of user.timezone at the start of LingeredAppSysProps.main(), now user.timezone shows up in all 4 lists. thanks, Chris From serguei.spitsyn at oracle.com Wed Apr 8 05:19:57 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Apr 2020 22:19:57 -0700 Subject: RFR(M) 8240990: convert clhsdb "dumpclass" command from javascript to java In-Reply-To: <4c0c5c3e-4c6e-ac52-cb8a-8aed6592a2cb@oracle.com> References: <4c0c5c3e-4c6e-ac52-cb8a-8aed6592a2cb@oracle.com> Message-ID: Hi Chris, It looks good to me. Thanks, Serguei On 4/7/20 20:12, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8240990 > http://cr.openjdk.java.net/~cjplummer/8240990/webrev.00 > > The javascript code was just a few lines like other recent commands, > but it had quite a bit of support on the java side in > JSJavaScriptEngine.dumpClass(), which needed some massaging when moved > to CommandProcessor.java. The CR contains the javascript and java code > that was converted. > > thanks, > > Chris From serguei.spitsyn at oracle.com Wed Apr 8 05:26:41 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Apr 2020 22:26:41 -0700 (PDT) Subject: RFR(XS) 8242265: serviceability/sa/ClhsdbScanOops.java fails due to bad @requires expression In-Reply-To: References: Message-ID: It looks good and trivial. Thanks, Serguei On 4/7/20 21:57, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242265 > > diff --git a/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java > b/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java > --- a/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java > +++ b/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java > @@ -25,7 +25,7 @@ > ? * @test > ? * @bug 8192985 > ? * @summary Test the clhsdb 'scanoops' command > - * @requires vm.gc.ParallelGC > + * @requires vm.gc.Parallel > ? * @requires vm.hasSA > ? * @library /test/lib > ? * @run main/othervm/timeout=1200 ClhsdbScanOops UseParallelGC > @@ -35,7 +35,7 @@ > ? * @test > ? * @bug 8192985 > ? * @summary Test the clhsdb 'scanoops' command > - * @requires vm.gc.SerialGC > + * @requires vm.gc.Serial > ? * @requires vm.hasSA > ? * @library /test/lib > ? * @run main/othervm/timeout=1200 ClhsdbScanOops UseSerialGC > > I tested by removing the tests from our problem list so now they are > actually run (and would see the reported failure if not fixed). > > thanks, > > Chris > From leonid.mesnik at oracle.com Wed Apr 8 05:38:58 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 7 Apr 2020 22:38:58 -0700 Subject: RFR(XS) 8242265: serviceability/sa/ClhsdbScanOops.java fails due to bad @requires expression In-Reply-To: References: Message-ID: <609606A7-46E8-4139-843C-104227E9E2B5@oracle.com> Looks good, thank you for fixing this. Leonid > On Apr 7, 2020, at 9:57 PM, Chris Plummer wrote: > > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242265 > > diff --git a/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java b/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java > --- a/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java > +++ b/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java > @@ -25,7 +25,7 @@ > * @test > * @bug 8192985 > * @summary Test the clhsdb 'scanoops' command > - * @requires vm.gc.ParallelGC > + * @requires vm.gc.Parallel > * @requires vm.hasSA > * @library /test/lib > * @run main/othervm/timeout=1200 ClhsdbScanOops UseParallelGC > @@ -35,7 +35,7 @@ > * @test > * @bug 8192985 > * @summary Test the clhsdb 'scanoops' command > - * @requires vm.gc.SerialGC > + * @requires vm.gc.Serial > * @requires vm.hasSA > * @library /test/lib > * @run main/othervm/timeout=1200 ClhsdbScanOops UseSerialGC > > I tested by removing the tests from our problem list so now they are actually run (and would see the reported failure if not fixed). > > thanks, > > Chris > From serguei.spitsyn at oracle.com Wed Apr 8 05:54:04 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Apr 2020 22:54:04 -0700 (PDT) Subject: RFR(S) 8242162: convert clhsdb "sysprops" command from javascript to java In-Reply-To: <5f166f1c-c1b2-c042-5b23-94e8d5d6f33d@oracle.com> References: <5f166f1c-c1b2-c042-5b23-94e8d5d6f33d@oracle.com> Message-ID: Chris, Refactored version looks nice. I was thinking to suggest the same in previous review but decided there is not a big profit for small blocks of code. But it is obvious now that it is clearly better. :) Thanks, Serguei On 4/7/20 22:15, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242162 > http://cr.openjdk.java.net/~cjplummer/8242162/webrev.00 > http://cr.openjdk.java.net/~cjplummer/8242162/webrev.01 > > Note there are two webrevs. You can skip the first if you want. It's > the initial straight forward implementation. After that I did > refactoring, so it might be easier if you looked at webrev.00 first > without the refactoring, but I will be pushing webrev.01. > > [Serguei, regarding the refactoring you suggested, I didn't find it > was worth doing for the execution of the commands since there are 4 of > them, and they all have subtle differences that makes it hard to > refactor in a productive way. I did refactor comparing the lists and > counting the lists.] > > Regarding the change in LingeredAppSysProps.java, I ran into an issue > when I added the clhsdb test. I was suddenly seeing an extra property. > It was user.timezone. I did some research and found that user.timezone > is kind of special. If not set on the command line it will not be > created until someone calls TimeZone.getDefault(). What?s interesting > is that when using the Attach API to get the sysprops (using jinfo or > jcmd), the first time you do this you don?t get back user.timezone, > but repeat the command and you do. Somehow the first time the command > is executed it triggers the initialization of user.timezone, but only > after the sysprops result was generated. So in the test > LingeredAppSysProps.main() was printing the properties without > use.name, and so was "jhsdb jinfo" and "jinfo". But the last "jinfo" > command triggered the initialization of user.timezone, so it turned up > in the subsequent run of "clhsdb sysprops", and thus the count in that > list was one higher than the rest. By forcing the initialization of > user.timezone at the start of LingeredAppSysProps.main(), now > user.timezone shows up in all 4 lists. > > thanks, > > Chris > From igor.ignatyev at oracle.com Wed Apr 8 17:21:18 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 8 Apr 2020 10:21:18 -0700 Subject: RFR(S/T) : 8242313 : use reproducible random in hotspot svc tests Message-ID: <963A7599-45FD-421A-AB68-09188F290791@oracle.com> http://cr.openjdk.java.net/~iignatyev//8242313/webrev.00 > 16 lines changed: 10 ins; 0 del; 6 mod; Hi all, could you please review the patch which updates hotspot/jtreg/serviceability tests in the same way as 8242310[1,2] updates compiler tests: > marks ... tests w/ randomness k/w and uses Utils.getRandomInstance() instead of Random w/ _random_ seeds where possible? To identify tests which should be marked, I've used both static (in a form of analyzing classes which directly or indirectly depend on Random/SecureRandom/ThreadLocalRandom) and dynamic (by instrumenting the said classes to log tests which called their 'next' methods) analyses. I've decided *not* to mark tests which use SecureRandom only via File.createTemp* b/c in all such cases temp files are not used as a source of randomness, but rather just a reliable way to get a new/empty file/dir. JBS: https://bugs.openjdk.java.net/browse/JDK-8242313 webrev: http://cr.openjdk.java.net/~iignatyev/8242313/webrev.00 NB the patch depends on 8241707[3], which is currently under review[4]. [1] https://bugs.openjdk.java.net/browse/JDK-8242310 [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037828.html [3] https://bugs.openjdk.java.net/browse/JDK-8241707 [4] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041300.html Thanks, -- Igor From chris.plummer at oracle.com Wed Apr 8 18:54:53 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 Apr 2020 11:54:53 -0700 Subject: RFR(XS) 8242384: sa/TestSysProps.java failed due to "RuntimeException: Could not find property in jinfo output: [0.058s][info][cds] Archive was created with UseCompressedOops" Message-ID: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8242384 http://cr.openjdk.java.net/~cjplummer/8242384/webrev.00/ The failure was occurring when running the test with -Xlog:cds=debug, which produced a logging output line that was mistaken for a property. The test now skips all output until it see the start of the properties list. It now passes locally for me when -Xlog:cds=debug is used. I'm still waiting for the tier4 test run to complete. thanks, Chris From daniel.daugherty at oracle.com Wed Apr 8 19:10:00 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Apr 2020 15:10:00 -0400 Subject: RFR(XS) 8242384: sa/TestSysProps.java failed due to "RuntimeException: Could not find property in jinfo output: [0.058s][info][cds] Archive was created with UseCompressedOops" In-Reply-To: References: Message-ID: Is it possible that some logging output that may occur after the key string ("-- listing properties --") is observed will confuse the test? I suspect not, but I wanted to ask to be sure... Thumbs up. Dan On 4/8/20 2:54 PM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242384 > http://cr.openjdk.java.net/~cjplummer/8242384/webrev.00/ > > The failure was occurring when running the test with -Xlog:cds=debug, > which produced a logging output line that was mistaken for a property. > The test now skips all output until it see the start of the properties > list. > > It now passes locally for me when -Xlog:cds=debug is used. I'm still > waiting for the tier4 test run to complete. > > thanks, > > Chris From chris.plummer at oracle.com Wed Apr 8 19:31:09 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 Apr 2020 12:31:09 -0700 Subject: RFR(XS) 8242384: sa/TestSysProps.java failed due to "RuntimeException: Could not find property in jinfo output: [0.058s][info][cds] Archive was created with UseCompressedOops" In-Reply-To: References: Message-ID: <3a89b57a-a994-4c3f-4e79-ab8f737dbb17@oracle.com> It's possible, but I think given how our tests are run by CI it will never happen. Also in order to mess up the test the output would need to have an '=' in it. In general it's pretty easy to break our tests by turning on things like logging or sprinkling debugging printfs the hotspot or library code. I've run into that many times. So I think we mostly just focus on the tests passing when run in more "normal" fashion. Chris On 4/8/20 12:10 PM, Daniel D. Daugherty wrote: > Is it possible that some logging output that may occur after the key > string > ("-- listing properties --") is observed will confuse the test? I suspect > not, but I wanted to ask to be sure... > > Thumbs up. > > Dan > > On 4/8/20 2:54 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8242384 >> http://cr.openjdk.java.net/~cjplummer/8242384/webrev.00/ >> >> The failure was occurring when running the test with -Xlog:cds=debug, >> which produced a logging output line that was mistaken for a >> property. The test now skips all output until it see the start of the >> properties list. >> >> It now passes locally for me when -Xlog:cds=debug is used. I'm still >> waiting for the tier4 test run to complete. >> >> thanks, >> >> Chris > From chris.plummer at oracle.com Wed Apr 8 20:07:35 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 Apr 2020 13:07:35 -0700 Subject: RFR(XS) 8242384: sa/TestSysProps.java failed due to "RuntimeException: Could not find property in jinfo output: [0.058s][info][cds] Archive was created with UseCompressedOops" In-Reply-To: <3a89b57a-a994-4c3f-4e79-ab8f737dbb17@oracle.com> References: <3a89b57a-a994-4c3f-4e79-ab8f737dbb17@oracle.com> Message-ID: <35e12c0e-35ab-a143-1351-5250637f4b7f@oracle.com> Should I go ahead and push this, or do you want to see another review? Chris On 4/8/20 12:31 PM, Chris Plummer wrote: > It's possible, but I think given how our tests are run by CI it will > never happen. Also in order to mess up the test the output would need > to have an '=' in it. In general it's pretty easy to break our tests > by turning on things like logging or sprinkling debugging printfs the > hotspot or library code. I've run into that many times. So I think we > mostly just focus on the tests passing when run in more "normal" fashion. > > Chris > > On 4/8/20 12:10 PM, Daniel D. Daugherty wrote: >> Is it possible that some logging output that may occur after the key >> string >> ("-- listing properties --") is observed will confuse the test? I >> suspect >> not, but I wanted to ask to be sure... >> >> Thumbs up. >> >> Dan >> >> On 4/8/20 2:54 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8242384 >>> http://cr.openjdk.java.net/~cjplummer/8242384/webrev.00/ >>> >>> The failure was occurring when running the test with >>> -Xlog:cds=debug, which produced a logging output line that was >>> mistaken for a property. The test now skips all output until it see >>> the start of the properties list. >>> >>> It now passes locally for me when -Xlog:cds=debug is used. I'm still >>> waiting for the tier4 test run to complete. >>> >>> thanks, >>> >>> Chris >> > From daniel.daugherty at oracle.com Wed Apr 8 20:21:23 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Apr 2020 16:21:23 -0400 Subject: RFR(XS) 8242384: sa/TestSysProps.java failed due to "RuntimeException: Could not find property in jinfo output: [0.058s][info][cds] Archive was created with UseCompressedOops" In-Reply-To: <35e12c0e-35ab-a143-1351-5250637f4b7f@oracle.com> References: <3a89b57a-a994-4c3f-4e79-ab8f737dbb17@oracle.com> <35e12c0e-35ab-a143-1351-5250637f4b7f@oracle.com> Message-ID: <4270fa03-5e4c-1bad-3e79-c6f3a5348ec0@oracle.com> To reiterate: > Thumbs up. Dan On 4/8/20 4:07 PM, Chris Plummer wrote: > Should I go ahead and push this, or do you want to see another review? > > Chris > > On 4/8/20 12:31 PM, Chris Plummer wrote: >> It's possible, but I think given how our tests are run by CI it will >> never happen. Also in order to mess up the test the output would need >> to have an '=' in it. In general it's pretty easy to break our tests >> by turning on things like logging or sprinkling debugging printfs the >> hotspot or library code. I've run into that many times. So I think we >> mostly just focus on the tests passing when run in more "normal" >> fashion. >> >> Chris >> >> On 4/8/20 12:10 PM, Daniel D. Daugherty wrote: >>> Is it possible that some logging output that may occur after the key >>> string >>> ("-- listing properties --") is observed will confuse the test? I >>> suspect >>> not, but I wanted to ask to be sure... >>> >>> Thumbs up. >>> >>> Dan >>> >>> On 4/8/20 2:54 PM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8242384 >>>> http://cr.openjdk.java.net/~cjplummer/8242384/webrev.00/ >>>> >>>> The failure was occurring when running the test with >>>> -Xlog:cds=debug, which produced a logging output line that was >>>> mistaken for a property. The test now skips all output until it see >>>> the start of the properties list. >>>> >>>> It now passes locally for me when -Xlog:cds=debug is used. I'm >>>> still waiting for the tier4 test run to complete. >>>> >>>> thanks, >>>> >>>> Chris >>> >> > From daniel.daugherty at oracle.com Wed Apr 8 20:23:29 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Apr 2020 16:23:29 -0400 Subject: RFR(XS) 8242384: sa/TestSysProps.java failed due to "RuntimeException: Could not find property in jinfo output: [0.058s][info][cds] Archive was created with UseCompressedOops" In-Reply-To: <4270fa03-5e4c-1bad-3e79-c6f3a5348ec0@oracle.com> References: <3a89b57a-a994-4c3f-4e79-ab8f737dbb17@oracle.com> <35e12c0e-35ab-a143-1351-5250637f4b7f@oracle.com> <4270fa03-5e4c-1bad-3e79-c6f3a5348ec0@oracle.com> Message-ID: Also, even though you did not ask for an "RFR(T)", I think this is a trivial fix. You don't have to wait for 24 hours and can push when you are happy with your testing. Dan On 4/8/20 4:21 PM, Daniel D. Daugherty wrote: > To reiterate: > > > Thumbs up. > > Dan > > On 4/8/20 4:07 PM, Chris Plummer wrote: >> Should I go ahead and push this, or do you want to see another review? >> >> Chris >> >> On 4/8/20 12:31 PM, Chris Plummer wrote: >>> It's possible, but I think given how our tests are run by CI it will >>> never happen. Also in order to mess up the test the output would >>> need to have an '=' in it. In general it's pretty easy to break our >>> tests by turning on things like logging or sprinkling debugging >>> printfs the hotspot or library code. I've run into that many times. >>> So I think we mostly just focus on the tests passing when run in >>> more "normal" fashion. >>> >>> Chris >>> >>> On 4/8/20 12:10 PM, Daniel D. Daugherty wrote: >>>> Is it possible that some logging output that may occur after the >>>> key string >>>> ("-- listing properties --") is observed will confuse the test? I >>>> suspect >>>> not, but I wanted to ask to be sure... >>>> >>>> Thumbs up. >>>> >>>> Dan >>>> >>>> On 4/8/20 2:54 PM, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8242384 >>>>> http://cr.openjdk.java.net/~cjplummer/8242384/webrev.00/ >>>>> >>>>> The failure was occurring when running the test with >>>>> -Xlog:cds=debug, which produced a logging output line that was >>>>> mistaken for a property. The test now skips all output until it >>>>> see the start of the properties list. >>>>> >>>>> It now passes locally for me when -Xlog:cds=debug is used. I'm >>>>> still waiting for the tier4 test run to complete. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>> >>> >> > From chris.plummer at oracle.com Wed Apr 8 20:24:40 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 Apr 2020 13:24:40 -0700 Subject: RFR(XS) 8242384: sa/TestSysProps.java failed due to "RuntimeException: Could not find property in jinfo output: [0.058s][info][cds] Archive was created with UseCompressedOops" In-Reply-To: References: <3a89b57a-a994-4c3f-4e79-ab8f737dbb17@oracle.com> <35e12c0e-35ab-a143-1351-5250637f4b7f@oracle.com> <4270fa03-5e4c-1bad-3e79-c6f3a5348ec0@oracle.com> Message-ID: <88f35903-8908-c3a1-10a8-036e2fb13aad@oracle.com> Ok. Thanks! Chris On 4/8/20 1:23 PM, Daniel D. Daugherty wrote: > Also, even though you did not ask for an "RFR(T)", I think this is > a trivial fix. You don't have to wait for 24 hours and can push when > you are happy with your testing. > > Dan > > > On 4/8/20 4:21 PM, Daniel D. Daugherty wrote: >> To reiterate: >> >> > Thumbs up. >> >> Dan >> >> On 4/8/20 4:07 PM, Chris Plummer wrote: >>> Should I go ahead and push this, or do you want to see another review? >>> >>> Chris >>> >>> On 4/8/20 12:31 PM, Chris Plummer wrote: >>>> It's possible, but I think given how our tests are run by CI it >>>> will never happen. Also in order to mess up the test the output >>>> would need to have an '=' in it. In general it's pretty easy to >>>> break our tests by turning on things like logging or sprinkling >>>> debugging printfs the hotspot or library code. I've run into that >>>> many times. So I think we mostly just focus on the tests passing >>>> when run in more "normal" fashion. >>>> >>>> Chris >>>> >>>> On 4/8/20 12:10 PM, Daniel D. Daugherty wrote: >>>>> Is it possible that some logging output that may occur after the >>>>> key string >>>>> ("-- listing properties --") is observed will confuse the test? I >>>>> suspect >>>>> not, but I wanted to ask to be sure... >>>>> >>>>> Thumbs up. >>>>> >>>>> Dan >>>>> >>>>> On 4/8/20 2:54 PM, Chris Plummer wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8242384 >>>>>> http://cr.openjdk.java.net/~cjplummer/8242384/webrev.00/ >>>>>> >>>>>> The failure was occurring when running the test with >>>>>> -Xlog:cds=debug, which produced a logging output line that was >>>>>> mistaken for a property. The test now skips all output until it >>>>>> see the start of the properties list. >>>>>> >>>>>> It now passes locally for me when -Xlog:cds=debug is used. I'm >>>>>> still waiting for the tier4 test run to complete. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>> >>>> >>> >> > From chris.plummer at oracle.com Thu Apr 9 02:08:05 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 Apr 2020 19:08:05 -0700 Subject: RFR(S) 8242162: convert clhsdb "sysprops" command from javascript to java In-Reply-To: References: <5f166f1c-c1b2-c042-5b23-94e8d5d6f33d@oracle.com> Message-ID: Thanks Serguei! Can I get one more review please? thanks, Chris On 4/7/20 10:54 PM, serguei.spitsyn at oracle.com wrote: > Chris, > > Refactored version looks nice. > I was thinking to suggest the same in previous review but decided > there is not a big profit for small blocks of code. > But it is obvious now that it is clearly better. :) > > Thanks, > Serguei > > > On 4/7/20 22:15, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8242162 >> http://cr.openjdk.java.net/~cjplummer/8242162/webrev.00 >> http://cr.openjdk.java.net/~cjplummer/8242162/webrev.01 >> >> Note there are two webrevs. You can skip the first if you want. It's >> the initial straight forward implementation. After that I did >> refactoring, so it might be easier if you looked at webrev.00 first >> without the refactoring, but I will be pushing webrev.01. >> >> [Serguei, regarding the refactoring you suggested, I didn't find it >> was worth doing for the execution of the commands since there are 4 >> of them, and they all have subtle differences that makes it hard to >> refactor in a productive way. I did refactor comparing the lists and >> counting the lists.] >> >> Regarding the change in LingeredAppSysProps.java, I ran into an issue >> when I added the clhsdb test. I was suddenly seeing an extra >> property. It was user.timezone. I did some research and found that >> user.timezone is kind of special. If not set on the command line it >> will not be created until someone calls TimeZone.getDefault(). What?s >> interesting is that when using the Attach API to get the sysprops >> (using jinfo or jcmd), the first time you do this you don?t get back >> user.timezone, but repeat the command and you do. Somehow the first >> time the command is executed it triggers the initialization of >> user.timezone, but only after the sysprops result was generated. So >> in the test LingeredAppSysProps.main() was printing the properties >> without use.name, and so was "jhsdb jinfo" and "jinfo". But the last >> "jinfo" command triggered the initialization of user.timezone, so it >> turned up in the subsequent run of "clhsdb sysprops", and thus the >> count in that list was one higher than the rest. By forcing the >> initialization of user.timezone at the start of >> LingeredAppSysProps.main(), now user.timezone shows up in all 4 lists. >> >> thanks, >> >> Chris >> > From chris.plummer at oracle.com Thu Apr 9 02:08:50 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 Apr 2020 19:08:50 -0700 Subject: RFR(M) 8240990: convert clhsdb "dumpclass" command from javascript to java In-Reply-To: References: <4c0c5c3e-4c6e-ac52-cb8a-8aed6592a2cb@oracle.com> Message-ID: <25587cee-ce47-8e4a-b75a-b4d30a6a6f79@oracle.com> Thanks Serguei, Can I get one more review please? thanks, Chris On 4/7/20 10:19 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > It looks good to me. > > Thanks, > Serguei > > On 4/7/20 20:12, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8240990 >> http://cr.openjdk.java.net/~cjplummer/8240990/webrev.00 >> >> The javascript code was just a few lines like other recent commands, >> but it had quite a bit of support on the java side in >> JSJavaScriptEngine.dumpClass(), which needed some massaging when >> moved to CommandProcessor.java. The CR contains the javascript and >> java code that was converted. >> >> thanks, >> >> Chris > From serguei.spitsyn at oracle.com Thu Apr 9 02:15:02 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 8 Apr 2020 19:15:02 -0700 Subject: PING: Re: RFR (XS): 8242241: add assert to ClassUnloadEventImpl::className In-Reply-To: <6c66916f-ccdf-6d16-ae98-a20eea48b7fe@oracle.com> References: <6c66916f-ccdf-6d16-ae98-a20eea48b7fe@oracle.com> Message-ID: <10868d3d-91c2-9d42-0de3-0835828a9a96@oracle.com> This is a one-liner fix. :) Thanks, Serguei On 4/7/20 15:39, serguei.spitsyn at oracle.com wrote: > Please, review a fix for minor JDI enhancement: > https://bugs.openjdk.java.net/browse/JDK-8242241 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/8242241-jdi-add-assert.1/ > > Summary: > ? A useful assert is introduced to check the class signature format is > correct. > > Testing: > ? The mach5 tier5 results are good. > > Thanks, > Serguei > > > From suenaga at oss.nttdata.com Thu Apr 9 02:37:43 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 9 Apr 2020 11:37:43 +0900 Subject: RFR(S) 8242162: convert clhsdb "sysprops" command from javascript to java In-Reply-To: References: <5f166f1c-c1b2-c042-5b23-94e8d5d6f33d@oracle.com> Message-ID: <1f219114-ea5d-eb5e-8bfb-748cbfebb150@oss.nttdata.com> Looks good! Yasumasa On 2020/04/09 11:08, Chris Plummer wrote: > Thanks Serguei! > > Can I get one more review please? > > thanks, > > Chris > > On 4/7/20 10:54 PM, serguei.spitsyn at oracle.com wrote: >> Chris, >> >> Refactored version looks nice. >> I was thinking to suggest the same in previous review but decided there is not a big profit for small blocks of code. >> But it is obvious now that it is clearly better. :) >> >> Thanks, >> Serguei >> >> >> On 4/7/20 22:15, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8242162 >>> http://cr.openjdk.java.net/~cjplummer/8242162/webrev.00 >>> http://cr.openjdk.java.net/~cjplummer/8242162/webrev.01 >>> >>> Note there are two webrevs. You can skip the first if you want. It's the initial straight forward implementation. After that I did refactoring, so it might be easier if you looked at webrev.00 first without the refactoring, but I will be pushing webrev.01. >>> >>> [Serguei, regarding the refactoring you suggested, I didn't find it was worth doing for the execution of the commands since there are 4 of them, and they all have subtle differences that makes it hard to refactor in a productive way. I did refactor comparing the lists and counting the lists.] >>> >>> Regarding the change in LingeredAppSysProps.java, I ran into an issue when I added the clhsdb test. I was suddenly seeing an extra property. It was user.timezone. I did some research and found that user.timezone is kind of special. If not set on the command line it will not be created until someone calls TimeZone.getDefault(). What?s interesting is that when using the Attach API to get the sysprops (using jinfo or jcmd), the first time you do this you don?t get back user.timezone, but repeat the command and you do. Somehow the first time the command is executed it triggers the initialization of user.timezone, but only after the sysprops result was generated. So in the test LingeredAppSysProps.main() was printing the properties without use.name, and so was "jhsdb jinfo" and "jinfo". But the last "jinfo" command triggered the initialization of user.timezone, so it turned up in the subsequent run of "clhsdb sysprops", and thus the count in that list was one higher than the >>> rest. By forcing the initialization of user.timezone at the start of LingeredAppSysProps.main(), now user.timezone shows up in all 4 lists. >>> >>> thanks, >>> >>> Chris >>> >> > > From suenaga at oss.nttdata.com Thu Apr 9 02:39:30 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 9 Apr 2020 11:39:30 +0900 Subject: RFR(M) 8240990: convert clhsdb "dumpclass" command from javascript to java In-Reply-To: <25587cee-ce47-8e4a-b75a-b4d30a6a6f79@oracle.com> References: <4c0c5c3e-4c6e-ac52-cb8a-8aed6592a2cb@oracle.com> <25587cee-ce47-8e4a-b75a-b4d30a6a6f79@oracle.com> Message-ID: <94135b0d-c616-f51a-34e4-c80864986e27@oss.nttdata.com> Hi Chris, CommandProcessor.java 1751 /* Dump the class file. */ 1752 try { 1753 int index = fileName.lastIndexOf(File.separatorChar); 1754 File dir = new File(fileName.substring(0, index)); 1755 dir.mkdirs(); 1756 FileOutputStream fos = new FileOutputStream(file); 1757 ClassWriter cw = new ClassWriter(ik, fos); 1758 cw.write(); 1759 fos.close(); 1760 } catch (Exception e) { 1761 err.println("Error: " + e); 1762 if (verboseExceptions) { 1763 e.printStackTrace(err); 1764 } 1765 } Can you use try-with-resources for `fos`? Thanks, Yasumasa On 2020/04/09 11:08, Chris Plummer wrote: > Thanks Serguei, > > Can I get one more review please? > > thanks, > > Chris > > On 4/7/20 10:19 PM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> It looks good to me. >> >> Thanks, >> Serguei >> >> On 4/7/20 20:12, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8240990 >>> http://cr.openjdk.java.net/~cjplummer/8240990/webrev.00 >>> >>> The javascript code was just a few lines like other recent commands, but it had quite a bit of support on the java side in JSJavaScriptEngine.dumpClass(), which needed some massaging when moved to CommandProcessor.java. The CR contains the javascript and java code that was converted. >>> >>> thanks, >>> >>> Chris >> > From chris.plummer at oracle.com Thu Apr 9 02:41:18 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 Apr 2020 19:41:18 -0700 Subject: PING: Re: RFR (XS): 8242241: add assert to ClassUnloadEventImpl::className In-Reply-To: <10868d3d-91c2-9d42-0de3-0835828a9a96@oracle.com> References: <6c66916f-ccdf-6d16-ae98-a20eea48b7fe@oracle.com> <10868d3d-91c2-9d42-0de3-0835828a9a96@oracle.com> Message-ID: LGTM Chris On 4/8/20 7:15 PM, serguei.spitsyn at oracle.com wrote: > This is a one-liner fix. :) > > Thanks, > Serguei > > > On 4/7/20 15:39, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for minor JDI enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8242241 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/8242241-jdi-add-assert.1/ >> >> >> Summary: >> ? A useful assert is introduced to check the class signature format >> is correct. >> >> Testing: >> ? The mach5 tier5 results are good. >> >> Thanks, >> Serguei >> >> >> > From serguei.spitsyn at oracle.com Thu Apr 9 02:44:16 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 8 Apr 2020 19:44:16 -0700 Subject: PING: Re: RFR (XS): 8242241: add assert to ClassUnloadEventImpl::className In-Reply-To: References: <6c66916f-ccdf-6d16-ae98-a20eea48b7fe@oracle.com> <10868d3d-91c2-9d42-0de3-0835828a9a96@oracle.com> Message-ID: Thanks, Chris! Serguei On 4/8/20 19:41, Chris Plummer wrote: > LGTM > > Chris > > On 4/8/20 7:15 PM, serguei.spitsyn at oracle.com wrote: >> This is a one-liner fix. :) >> >> Thanks, >> Serguei >> >> >> On 4/7/20 15:39, serguei.spitsyn at oracle.com wrote: >>> Please, review a fix for minor JDI enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8242241 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/8242241-jdi-add-assert.1/ >>> >>> >>> Summary: >>> ? A useful assert is introduced to check the class signature format >>> is correct. >>> >>> Testing: >>> ? The mach5 tier5 results are good. >>> >>> Thanks, >>> Serguei >>> >>> >>> >> > > From chris.plummer at oracle.com Thu Apr 9 02:57:48 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 Apr 2020 19:57:48 -0700 Subject: RFR(M) 8240990: convert clhsdb "dumpclass" command from javascript to java In-Reply-To: <94135b0d-c616-f51a-34e4-c80864986e27@oss.nttdata.com> References: <4c0c5c3e-4c6e-ac52-cb8a-8aed6592a2cb@oracle.com> <25587cee-ce47-8e4a-b75a-b4d30a6a6f79@oracle.com> <94135b0d-c616-f51a-34e4-c80864986e27@oss.nttdata.com> Message-ID: Like this? ??????????????? /* Dump the class file. */ ??????????????? try { ??????????????????? int index = fileName.lastIndexOf(File.separatorChar); ??????????????????? File dir = new File(fileName.substring(0, index)); ??????????????????? dir.mkdirs(); ??????????????????? try (FileOutputStream fos = new FileOutputStream(file)) { ??????????????????????? ClassWriter cw = new ClassWriter(ik, fos); ??????????????????????? cw.write(); ??????????????????? } ??????????????? } catch (Exception e) { ??????????????????? err.println("Error: " + e); ??????????????????? if (verboseExceptions) { ??????????????????????? e.printStackTrace(err); ??????????????????? } ??????????????? } Chris On 4/8/20 7:39 PM, Yasumasa Suenaga wrote: > Hi Chris, > > CommandProcessor.java > > 1751???????????????? /* Dump the class file. */ > 1752???????????????? try { > 1753???????????????????? int index = > fileName.lastIndexOf(File.separatorChar); > 1754???????????????????? File dir = new File(fileName.substring(0, > index)); > 1755???????????????????? dir.mkdirs(); > 1756???????????????????? FileOutputStream fos = new > FileOutputStream(file); > 1757???????????????????? ClassWriter cw = new ClassWriter(ik, fos); > 1758???????????????????? cw.write(); > 1759???????????????????? fos.close(); > 1760???????????????? } catch (Exception e) { > 1761???????????????????? err.println("Error: " + e); > 1762???????????????????? if (verboseExceptions) { > 1763???????????????????????? e.printStackTrace(err); > 1764???????????????????? } > 1765???????????????? } > > Can you use try-with-resources for `fos`? > > > Thanks, > > Yasumasa > > > On 2020/04/09 11:08, Chris Plummer wrote: >> Thanks Serguei, >> >> Can I get one more review please? >> >> thanks, >> >> Chris >> >> On 4/7/20 10:19 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Chris, >>> >>> It looks good to me. >>> >>> Thanks, >>> Serguei >>> >>> On 4/7/20 20:12, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8240990 >>>> http://cr.openjdk.java.net/~cjplummer/8240990/webrev.00 >>>> >>>> The javascript code was just a few lines like other recent >>>> commands, but it had quite a bit of support on the java side in >>>> JSJavaScriptEngine.dumpClass(), which needed some massaging when >>>> moved to CommandProcessor.java. The CR contains the javascript and >>>> java code that was converted. >>>> >>>> thanks, >>>> >>>> Chris >>> >> From chris.plummer at oracle.com Thu Apr 9 02:59:06 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 Apr 2020 19:59:06 -0700 Subject: RFR(S) 8242162: convert clhsdb "sysprops" command from javascript to java In-Reply-To: <1f219114-ea5d-eb5e-8bfb-748cbfebb150@oss.nttdata.com> References: <5f166f1c-c1b2-c042-5b23-94e8d5d6f33d@oracle.com> <1f219114-ea5d-eb5e-8bfb-748cbfebb150@oss.nttdata.com> Message-ID: Thanks Yasumasa! Chris On 4/8/20 7:37 PM, Yasumasa Suenaga wrote: > Looks good! > > Yasumasa > > On 2020/04/09 11:08, Chris Plummer wrote: >> Thanks Serguei! >> >> Can I get one more review please? >> >> thanks, >> >> Chris >> >> On 4/7/20 10:54 PM, serguei.spitsyn at oracle.com wrote: >>> Chris, >>> >>> Refactored version looks nice. >>> I was thinking to suggest the same in previous review but decided >>> there is not a big profit for small blocks of code. >>> But it is obvious now that it is clearly better. :) >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/7/20 22:15, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8242162 >>>> http://cr.openjdk.java.net/~cjplummer/8242162/webrev.00 >>>> http://cr.openjdk.java.net/~cjplummer/8242162/webrev.01 >>>> >>>> Note there are two webrevs. You can skip the first if you want. >>>> It's the initial straight forward implementation. After that I did >>>> refactoring, so it might be easier if you looked at webrev.00 first >>>> without the refactoring, but I will be pushing webrev.01. >>>> >>>> [Serguei, regarding the refactoring you suggested, I didn't find it >>>> was worth doing for the execution of the commands since there are 4 >>>> of them, and they all have subtle differences that makes it hard to >>>> refactor in a productive way. I did refactor comparing the lists >>>> and counting the lists.] >>>> >>>> Regarding the change in LingeredAppSysProps.java, I ran into an >>>> issue when I added the clhsdb test. I was suddenly seeing an extra >>>> property. It was user.timezone. I did some research and found that >>>> user.timezone is kind of special. If not set on the command line it >>>> will not be created until someone calls TimeZone.getDefault(). >>>> What?s interesting is that when using the Attach API to get the >>>> sysprops (using jinfo or jcmd), the first time you do this you >>>> don?t get back user.timezone, but repeat the command and you do. >>>> Somehow the first time the command is executed it triggers the >>>> initialization of user.timezone, but only after the sysprops result >>>> was generated. So in the test LingeredAppSysProps.main() was >>>> printing the properties without use.name, and so was "jhsdb jinfo" >>>> and "jinfo". But the last "jinfo" command triggered the >>>> initialization of user.timezone, so it turned up in the subsequent >>>> run of "clhsdb sysprops", and thus the count in that list was one >>>> higher than the rest. By forcing the initialization of >>>> user.timezone at the start of LingeredAppSysProps.main(), now >>>> user.timezone shows up in all 4 lists. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>> >> >> From suenaga at oss.nttdata.com Thu Apr 9 03:04:23 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 9 Apr 2020 12:04:23 +0900 Subject: RFR(M) 8240990: convert clhsdb "dumpclass" command from javascript to java In-Reply-To: References: <4c0c5c3e-4c6e-ac52-cb8a-8aed6592a2cb@oracle.com> <25587cee-ce47-8e4a-b75a-b4d30a6a6f79@oracle.com> <94135b0d-c616-f51a-34e4-c80864986e27@oss.nttdata.com> Message-ID: Yeah, it looks good! I think this change is more safely. Thanks, Yasumasa On 2020/04/09 11:57, Chris Plummer wrote: > Like this? > > ??????????????? /* Dump the class file. */ > ??????????????? try { > ??????????????????? int index = fileName.lastIndexOf(File.separatorChar); > ??????????????????? File dir = new File(fileName.substring(0, index)); > ??????????????????? dir.mkdirs(); > ??????????????????? try (FileOutputStream fos = new FileOutputStream(file)) { > ??????????????????????? ClassWriter cw = new ClassWriter(ik, fos); > ??????????????????????? cw.write(); > ??????????????????? } > ??????????????? } catch (Exception e) { > ??????????????????? err.println("Error: " + e); > ??????????????????? if (verboseExceptions) { > ??????????????????????? e.printStackTrace(err); > ??????????????????? } > ??????????????? } > > Chris > > On 4/8/20 7:39 PM, Yasumasa Suenaga wrote: >> Hi Chris, >> >> CommandProcessor.java >> >> 1751???????????????? /* Dump the class file. */ >> 1752???????????????? try { >> 1753???????????????????? int index = fileName.lastIndexOf(File.separatorChar); >> 1754???????????????????? File dir = new File(fileName.substring(0, index)); >> 1755???????????????????? dir.mkdirs(); >> 1756???????????????????? FileOutputStream fos = new FileOutputStream(file); >> 1757???????????????????? ClassWriter cw = new ClassWriter(ik, fos); >> 1758???????????????????? cw.write(); >> 1759???????????????????? fos.close(); >> 1760???????????????? } catch (Exception e) { >> 1761???????????????????? err.println("Error: " + e); >> 1762???????????????????? if (verboseExceptions) { >> 1763???????????????????????? e.printStackTrace(err); >> 1764???????????????????? } >> 1765???????????????? } >> >> Can you use try-with-resources for `fos`? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/09 11:08, Chris Plummer wrote: >>> Thanks Serguei, >>> >>> Can I get one more review please? >>> >>> thanks, >>> >>> Chris >>> >>> On 4/7/20 10:19 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Chris, >>>> >>>> It looks good to me. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 4/7/20 20:12, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8240990 >>>>> http://cr.openjdk.java.net/~cjplummer/8240990/webrev.00 >>>>> >>>>> The javascript code was just a few lines like other recent commands, but it had quite a bit of support on the java side in JSJavaScriptEngine.dumpClass(), which needed some massaging when moved to CommandProcessor.java. The CR contains the javascript and java code that was converted. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>> >>> > From chris.plummer at oracle.com Thu Apr 9 03:06:02 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 Apr 2020 20:06:02 -0700 Subject: RFR(M) 8240990: convert clhsdb "dumpclass" command from javascript to java In-Reply-To: References: <4c0c5c3e-4c6e-ac52-cb8a-8aed6592a2cb@oracle.com> <25587cee-ce47-8e4a-b75a-b4d30a6a6f79@oracle.com> <94135b0d-c616-f51a-34e4-c80864986e27@oss.nttdata.com> Message-ID: <8e8130bf-2ac1-dcc7-3ba4-fc2ab64b5ae0@oracle.com> Ok. Thanks for the review! Chris On 4/8/20 8:04 PM, Yasumasa Suenaga wrote: > Yeah, it looks good! > I think this change is more safely. > > > Thanks, > > Yasumasa > > > On 2020/04/09 11:57, Chris Plummer wrote: >> Like this? >> >> ???????????????? /* Dump the class file. */ >> ???????????????? try { >> ???????????????????? int index = >> fileName.lastIndexOf(File.separatorChar); >> ???????????????????? File dir = new File(fileName.substring(0, index)); >> ???????????????????? dir.mkdirs(); >> ???????????????????? try (FileOutputStream fos = new >> FileOutputStream(file)) { >> ???????????????????????? ClassWriter cw = new ClassWriter(ik, fos); >> ???????????????????????? cw.write(); >> ???????????????????? } >> ???????????????? } catch (Exception e) { >> ???????????????????? err.println("Error: " + e); >> ???????????????????? if (verboseExceptions) { >> ???????????????????????? e.printStackTrace(err); >> ???????????????????? } >> ???????????????? } >> >> Chris >> >> On 4/8/20 7:39 PM, Yasumasa Suenaga wrote: >>> Hi Chris, >>> >>> CommandProcessor.java >>> >>> 1751???????????????? /* Dump the class file. */ >>> 1752???????????????? try { >>> 1753???????????????????? int index = >>> fileName.lastIndexOf(File.separatorChar); >>> 1754???????????????????? File dir = new File(fileName.substring(0, >>> index)); >>> 1755???????????????????? dir.mkdirs(); >>> 1756???????????????????? FileOutputStream fos = new >>> FileOutputStream(file); >>> 1757???????????????????? ClassWriter cw = new ClassWriter(ik, fos); >>> 1758???????????????????? cw.write(); >>> 1759???????????????????? fos.close(); >>> 1760???????????????? } catch (Exception e) { >>> 1761???????????????????? err.println("Error: " + e); >>> 1762???????????????????? if (verboseExceptions) { >>> 1763???????????????????????? e.printStackTrace(err); >>> 1764???????????????????? } >>> 1765???????????????? } >>> >>> Can you use try-with-resources for `fos`? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/04/09 11:08, Chris Plummer wrote: >>>> Thanks Serguei, >>>> >>>> Can I get one more review please? >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 4/7/20 10:19 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Chris, >>>>> >>>>> It looks good to me. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 4/7/20 20:12, Chris Plummer wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8240990 >>>>>> http://cr.openjdk.java.net/~cjplummer/8240990/webrev.00 >>>>>> >>>>>> The javascript code was just a few lines like other recent >>>>>> commands, but it had quite a bit of support on the java side in >>>>>> JSJavaScriptEngine.dumpClass(), which needed some massaging when >>>>>> moved to CommandProcessor.java. The CR contains the javascript >>>>>> and java code that was converted. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>> >>>> >> From suenaga at oss.nttdata.com Thu Apr 9 05:08:36 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 9 Apr 2020 14:08:36 +0900 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: <1bd2bd6f-d51d-d02f-e2df-a4796c2a2d72@oss.nttdata.com> References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <8ced0d82-4125-7179-bac2-c8ce54807274@oracle.com> <936c63af-cbd0-234a-94e5-5bc03f237b3c@oracle.com> <1bd2bd6f-d51d-d02f-e2df-a4796c2a2d72@oss.nttdata.com> Message-ID: Hi, JDK-8240918 has been pushed, so I made a patch for GetCurrentContendedMonitor(). How about this? http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/2/ >>>>>>> An observation, it seems to me that calling_thread is not used when this is not a VMOperation. calling_thread is used for creating JNI reference: ``` *monitor_ptr = jni_reference(calling_thread, hobj); ``` If it is ok, I will make patches for other JVMTI functions. However the patch might be bigger, so I want to separate as below. What do you think? (I think we can file them as subtask under JDK-8201641) * Monitor operation - VM_GetOwnedMonitorInfo - VM_GetCurrentContendedMonitor * Frame operation - VM_UpdateForPopTopFrame - VM_SetFramePop * Thread operation - VM_GetFrameCount - VM_GetFrameLocation - VM_GetThreadListStackTraces - VM_GetCurrentLocation - VM_EnterInterpOnlyMode Thanks, Yasumasa On 2020/04/01 21:29, Yasumasa Suenaga wrote: > Thanks David! > > If JDK-8201641 is not assigned when JDK-8240918 is resolved, I will start to work for JDK-8201641. > (It would be large patch...) > > > Cheers, > > Yasumasa > > > On 2020/04/01 19:05, David Holmes wrote: >> On 1/04/2020 11:02 am, Yasumasa Suenaga wrote: >>> Thanks Dan and Serguei! >>> >>> I added a comment for this to JDK-8201641. >>> >>> David, can you share Bug ID for thread-to-thread handshake? >>> I want to record it to JDK-8201641 as a blocker. >> >> https://bugs.openjdk.java.net/browse/JDK-8240918 >> >> I heard the RFR could be as soon as tomorrow :) >> >> Cheers, >> David >> >>> >>> Yasumasa >>> >>> >>> On 2020/04/01 1:59, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> Yes, this works needs to be done. >>>> I'll take look at you webrev. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 3/31/20 07:41, Daniel D. Daugherty wrote: >>>>> Add Robbin to this thread... >>>>> >>>>> >>>>> This reminded of the following RFE that Robbin filed: >>>>> >>>>> ??? JDK-8201641 JVMTI: GetThreadListStackTraces should use Thread-Local Handshakes >>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8201641 >>>>> >>>>> We could update 8201641 to include everything that Yasumasa-san is requesting. >>>>> Would be a good place to track it... >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> On 2020/03/31 19:16, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Many JVMTI functions uses VM Operation to get information. However some of them need to stop only one thread - they don't need to stop all threads. >>>>>>>> So I think we can use Thread Local Handshake as this webrev. It is example for GetOneCurrentContendedMonitor(). >>>>>>> >>>>>>> True, but at the moment handshakes involve the VMThread. There is work being done to support direct thread-to-thread handshakes and once that is done this kind of conversion should be more easily done. It might be worth waiting for that. >>>>>> >>>>>> Thanks, I will be back to this topic when thread-to-thread handshake is done. >>>>>> I wondered at first why VMThread involves handshake. Its improvement is welcome for me ;) >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>>>> >>>>>>> An observation, it seems to me that calling_thread is not used when this is not a VMOperation. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> Also I think we can replace following VM Operations to Thread Local Handshake: >>>>>>>> >>>>>>>> class VM_GetCurrentLocation >>>>>>>> class VM_EnterInterpOnlyMode >>>>>>>> class VM_UpdateForPopTopFrame >>>>>>>> class VM_SetFramePop >>>>>>>> class VM_GetOwnedMonitorInfo >>>>>>>> class VM_GetCurrentContendedMonitor >>>>>>>> class VM_GetFrameCount >>>>>>>> class VM_GetFrameLocation >>>>>>>> >>>>>>>> What do you think? >>>>>>>> It it is acceptable, I will file it to JBS and send review request. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>> >>>> From david.holmes at oracle.com Thu Apr 9 05:52:03 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Apr 2020 15:52:03 +1000 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <8ced0d82-4125-7179-bac2-c8ce54807274@oracle.com> <936c63af-cbd0-234a-94e5-5bc03f237b3c@oracle.com> <1bd2bd6f-d51d-d02f-e2df-a4796c2a2d72@oss.nttdata.com> Message-ID: Hi Yasumasa, On 9/04/2020 3:08 pm, Yasumasa Suenaga wrote: > Hi, > > JDK-8240918 has been pushed, so I made a patch for > GetCurrentContendedMonitor(). How about this? > > ? http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/2/ Generally looks okay. A couple of comments: src/hotspot/share/prims/jvmtiEnv.cpp Please update the comment just before the change: // thread. All other usage needs to use a vm-safepoint-op for safety. --- GetOneCurrentContendedMonitor I don't think you need to add One into the name here - the current contended monitor is inherently a singleton. --- src/hotspot/share/prims/jvmtiEnvBase.cpp 655 Thread::current() == java_thread->active_handshaker() || The calling_thread parameter is now the current thread. So this can also be changed: 679 Handle hobj(Thread::current(), obj); >>>>>>>> An observation, it seems to me that calling_thread is not used >>>>>>>> when this is not a VMOperation. > > calling_thread is used for creating JNI reference: > > ``` > *monitor_ptr = jni_reference(calling_thread, hobj); > ``` > > > If it is ok, I will make patches for other JVMTI functions. > However the patch might be bigger, so I want to separate as below. What > do you think? > (I think we can file them as subtask under JDK-8201641) > > > * Monitor operation > ??? - VM_GetOwnedMonitorInfo > ??? - VM_GetCurrentContendedMonitor > > * Frame operation > ??? - VM_UpdateForPopTopFrame > ??? - VM_SetFramePop > > * Thread operation > ??? - VM_GetFrameCount > ??? - VM_GetFrameLocation > ??? - VM_GetThreadListStackTraces > ??? - VM_GetCurrentLocation > ??? - VM_EnterInterpOnlyMode Creating subtasks with separate RFRs is fine by me. It may be good to slowly introduce these changes so that we get some testing coverage to iron out any initial bugs with the approach. Thanks, David ----- > > Thanks, > > Yasumasa > > > On 2020/04/01 21:29, Yasumasa Suenaga wrote: >> Thanks David! >> >> If JDK-8201641 is not assigned when JDK-8240918 is resolved, I will >> start to work for JDK-8201641. >> (It would be large patch...) >> >> >> Cheers, >> >> Yasumasa >> >> >> On 2020/04/01 19:05, David Holmes wrote: >>> On 1/04/2020 11:02 am, Yasumasa Suenaga wrote: >>>> Thanks Dan and Serguei! >>>> >>>> I added a comment for this to JDK-8201641. >>>> >>>> David, can you share Bug ID for thread-to-thread handshake? >>>> I want to record it to JDK-8201641 as a blocker. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8240918 >>> >>> I heard the RFR could be as soon as tomorrow :) >>> >>> Cheers, >>> David >>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/04/01 1:59, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa, >>>>> >>>>> Yes, this works needs to be done. >>>>> I'll take look at you webrev. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 3/31/20 07:41, Daniel D. Daugherty wrote: >>>>>> Add Robbin to this thread... >>>>>> >>>>>> >>>>>> This reminded of the following RFE that Robbin filed: >>>>>> >>>>>> ??? JDK-8201641 JVMTI: GetThreadListStackTraces should use >>>>>> Thread-Local Handshakes >>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8201641 >>>>>> >>>>>> We could update 8201641 to include everything that Yasumasa-san is >>>>>> requesting. >>>>>> Would be a good place to track it... >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 2020/03/31 19:16, David Holmes wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Many JVMTI functions uses VM Operation to get information. >>>>>>>>> However some of them need to stop only one thread - they don't >>>>>>>>> need to stop all threads. >>>>>>>>> So I think we can use Thread Local Handshake as this webrev. It >>>>>>>>> is example for GetOneCurrentContendedMonitor(). >>>>>>>> >>>>>>>> True, but at the moment handshakes involve the VMThread. There >>>>>>>> is work being done to support direct thread-to-thread handshakes >>>>>>>> and once that is done this kind of conversion should be more >>>>>>>> easily done. It might be worth waiting for that. >>>>>>> >>>>>>> Thanks, I will be back to this topic when thread-to-thread >>>>>>> handshake is done. >>>>>>> I wondered at first why VMThread involves handshake. Its >>>>>>> improvement is welcome for me ;) >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>>>>> >>>>>>>> An observation, it seems to me that calling_thread is not used >>>>>>>> when this is not a VMOperation. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>>> Also I think we can replace following VM Operations to Thread >>>>>>>>> Local Handshake: >>>>>>>>> >>>>>>>>> class VM_GetCurrentLocation >>>>>>>>> class VM_EnterInterpOnlyMode >>>>>>>>> class VM_UpdateForPopTopFrame >>>>>>>>> class VM_SetFramePop >>>>>>>>> class VM_GetOwnedMonitorInfo >>>>>>>>> class VM_GetCurrentContendedMonitor >>>>>>>>> class VM_GetFrameCount >>>>>>>>> class VM_GetFrameLocation >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> It it is acceptable, I will file it to JBS and send review >>>>>>>>> request. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>> >>>>> From serguei.spitsyn at oracle.com Thu Apr 9 06:19:42 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 8 Apr 2020 23:19:42 -0700 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <8ced0d82-4125-7179-bac2-c8ce54807274@oracle.com> <936c63af-cbd0-234a-94e5-5bc03f237b3c@oracle.com> <1bd2bd6f-d51d-d02f-e2df-a4796c2a2d72@oss.nttdata.com> Message-ID: Hi Yasumasa, I'm okay with using sub-tasks to do it incrementally. This needs to be removed with your fix: ? src/hotspot/share/runtime/vmOperations.hpp: template(GetCurrentContendedMonitor)??????????? \ Also, I agree with comments from David below: ?- GetOneCurrentContendedMonitor => GetCurrentContendedMonitor ?- Thread::current() =>? calling_thread I hope, you will update the copyright comments in jvmtiEnvBase.?pp. Are you going to re-post this as an RFR with a correct sub-task number? Thanks, Serguei On 4/8/20 22:52, David Holmes wrote: > Hi Yasumasa, > > On 9/04/2020 3:08 pm, Yasumasa Suenaga wrote: >> Hi, >> >> JDK-8240918 has been pushed, so I made a patch for >> GetCurrentContendedMonitor(). How about this? >> >> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/2/ > > Generally looks okay. A couple of comments: > > src/hotspot/share/prims/jvmtiEnv.cpp > > Please update the comment just before the change: > > ?? // thread. All other usage needs to use a vm-safepoint-op for safety. > > --- > > ?GetOneCurrentContendedMonitor > > I don't think you need to add One into the name here - the current > contended monitor is inherently a singleton. > > --- > > src/hotspot/share/prims/jvmtiEnvBase.cpp > > 655?????????? Thread::current() == java_thread->active_handshaker() || > > The calling_thread parameter is now the current thread. So this can > also be changed: > > 679???? Handle???? hobj(Thread::current(), obj); > > > >>>>>>>>> An observation, it seems to me that calling_thread is not used >>>>>>>>> when this is not a VMOperation. >> >> calling_thread is used for creating JNI reference: >> >> ``` >> *monitor_ptr = jni_reference(calling_thread, hobj); >> ``` >> >> >> If it is ok, I will make patches for other JVMTI functions. >> However the patch might be bigger, so I want to separate as below. >> What do you think? >> (I think we can file them as subtask under JDK-8201641) >> >> >> * Monitor operation >> ???? - VM_GetOwnedMonitorInfo >> ???? - VM_GetCurrentContendedMonitor >> >> * Frame operation >> ???? - VM_UpdateForPopTopFrame >> ???? - VM_SetFramePop >> >> * Thread operation >> ???? - VM_GetFrameCount >> ???? - VM_GetFrameLocation >> ???? - VM_GetThreadListStackTraces >> ???? - VM_GetCurrentLocation >> ???? - VM_EnterInterpOnlyMode > > Creating subtasks with separate RFRs is fine by me. It may be good to > slowly introduce these changes so that we get some testing coverage to > iron out any initial bugs with the approach. > > Thanks, > David > ----- > >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/01 21:29, Yasumasa Suenaga wrote: >>> Thanks David! >>> >>> If JDK-8201641 is not assigned when JDK-8240918 is resolved, I will >>> start to work for JDK-8201641. >>> (It would be large patch...) >>> >>> >>> Cheers, >>> >>> Yasumasa >>> >>> >>> On 2020/04/01 19:05, David Holmes wrote: >>>> On 1/04/2020 11:02 am, Yasumasa Suenaga wrote: >>>>> Thanks Dan and Serguei! >>>>> >>>>> I added a comment for this to JDK-8201641. >>>>> >>>>> David, can you share Bug ID for thread-to-thread handshake? >>>>> I want to record it to JDK-8201641 as a blocker. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8240918 >>>> >>>> I heard the RFR could be as soon as tomorrow :) >>>> >>>> Cheers, >>>> David >>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2020/04/01 1:59, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Yes, this works needs to be done. >>>>>> I'll take look at you webrev. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 3/31/20 07:41, Daniel D. Daugherty wrote: >>>>>>> Add Robbin to this thread... >>>>>>> >>>>>>> >>>>>>> This reminded of the following RFE that Robbin filed: >>>>>>> >>>>>>> ??? JDK-8201641 JVMTI: GetThreadListStackTraces should use >>>>>>> Thread-Local Handshakes >>>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8201641 >>>>>>> >>>>>>> We could update 8201641 to include everything that Yasumasa-san >>>>>>> is requesting. >>>>>>> Would be a good place to track it... >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 2020/03/31 19:16, David Holmes wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Many JVMTI functions uses VM Operation to get information. >>>>>>>>>> However some of them need to stop only one thread - they >>>>>>>>>> don't need to stop all threads. >>>>>>>>>> So I think we can use Thread Local Handshake as this webrev. >>>>>>>>>> It is example for GetOneCurrentContendedMonitor(). >>>>>>>>> >>>>>>>>> True, but at the moment handshakes involve the VMThread. There >>>>>>>>> is work being done to support direct thread-to-thread >>>>>>>>> handshakes and once that is done this kind of conversion >>>>>>>>> should be more easily done. It might be worth waiting for that. >>>>>>>> >>>>>>>> Thanks, I will be back to this topic when thread-to-thread >>>>>>>> handshake is done. >>>>>>>> I wondered at first why VMThread involves handshake. Its >>>>>>>> improvement is welcome for me ;) >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>>>>>>> >>>>>>>>> >>>>>>>>> An observation, it seems to me that calling_thread is not used >>>>>>>>> when this is not a VMOperation. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Also I think we can replace following VM Operations to Thread >>>>>>>>>> Local Handshake: >>>>>>>>>> >>>>>>>>>> class VM_GetCurrentLocation >>>>>>>>>> class VM_EnterInterpOnlyMode >>>>>>>>>> class VM_UpdateForPopTopFrame >>>>>>>>>> class VM_SetFramePop >>>>>>>>>> class VM_GetOwnedMonitorInfo >>>>>>>>>> class VM_GetCurrentContendedMonitor >>>>>>>>>> class VM_GetFrameCount >>>>>>>>>> class VM_GetFrameLocation >>>>>>>>>> >>>>>>>>>> What do you think? >>>>>>>>>> It it is acceptable, I will file it to JBS and send review >>>>>>>>>> request. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>> >>>>>> From suenaga at oss.nttdata.com Thu Apr 9 06:36:27 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 9 Apr 2020 15:36:27 +0900 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <8ced0d82-4125-7179-bac2-c8ce54807274@oracle.com> <936c63af-cbd0-234a-94e5-5bc03f237b3c@oracle.com> <1bd2bd6f-d51d-d02f-e2df-a4796c2a2d72@oss.nttdata.com> Message-ID: Thanks David and Serguei! I created 3 subtasks under JDK-8201641, of course I will send review request in each them. > - GetOneCurrentContendedMonitor => GetCurrentContendedMonitor `GetCurrentContendedMonitor` is JVMTI function name, and also it exists as public member of JvmtiEnv class. So I want to different name for HandshakeClosure - for example, GetCurrentContendedMonitorClosure. Do you have any idea for it? Yasumasa On 2020/04/09 15:19, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > I'm okay with using sub-tasks to do it incrementally. > > This needs to be removed with your fix: > ? src/hotspot/share/runtime/vmOperations.hpp: template(GetCurrentContendedMonitor)??????????? \ > > Also, I agree with comments from David below: > ?- GetOneCurrentContendedMonitor => GetCurrentContendedMonitor > ?- Thread::current() =>? calling_thread > > I hope, you will update the copyright comments in jvmtiEnvBase.?pp. > > Are you going to re-post this as an RFR with a correct sub-task number? > > Thanks, > Serguei > > > On 4/8/20 22:52, David Holmes wrote: >> Hi Yasumasa, >> >> On 9/04/2020 3:08 pm, Yasumasa Suenaga wrote: >>> Hi, >>> >>> JDK-8240918 has been pushed, so I made a patch for GetCurrentContendedMonitor(). How about this? >>> >>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/2/ >> >> Generally looks okay. A couple of comments: >> >> src/hotspot/share/prims/jvmtiEnv.cpp >> >> Please update the comment just before the change: >> >> ?? // thread. All other usage needs to use a vm-safepoint-op for safety. >> >> --- >> >> ?GetOneCurrentContendedMonitor >> >> I don't think you need to add One into the name here - the current contended monitor is inherently a singleton. >> >> --- >> >> src/hotspot/share/prims/jvmtiEnvBase.cpp >> >> 655?????????? Thread::current() == java_thread->active_handshaker() || >> >> The calling_thread parameter is now the current thread. So this can also be changed: >> >> 679???? Handle???? hobj(Thread::current(), obj); >> >> >> >>>>>>>>>> An observation, it seems to me that calling_thread is not used when this is not a VMOperation. >>> >>> calling_thread is used for creating JNI reference: >>> >>> ``` >>> *monitor_ptr = jni_reference(calling_thread, hobj); >>> ``` >>> >>> >>> If it is ok, I will make patches for other JVMTI functions. >>> However the patch might be bigger, so I want to separate as below. What do you think? >>> (I think we can file them as subtask under JDK-8201641) >>> >>> >>> * Monitor operation >>> ???? - VM_GetOwnedMonitorInfo >>> ???? - VM_GetCurrentContendedMonitor >>> >>> * Frame operation >>> ???? - VM_UpdateForPopTopFrame >>> ???? - VM_SetFramePop >>> >>> * Thread operation >>> ???? - VM_GetFrameCount >>> ???? - VM_GetFrameLocation >>> ???? - VM_GetThreadListStackTraces >>> ???? - VM_GetCurrentLocation >>> ???? - VM_EnterInterpOnlyMode >> >> Creating subtasks with separate RFRs is fine by me. It may be good to slowly introduce these changes so that we get some testing coverage to iron out any initial bugs with the approach. >> >> Thanks, >> David >> ----- >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/04/01 21:29, Yasumasa Suenaga wrote: >>>> Thanks David! >>>> >>>> If JDK-8201641 is not assigned when JDK-8240918 is resolved, I will start to work for JDK-8201641. >>>> (It would be large patch...) >>>> >>>> >>>> Cheers, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/04/01 19:05, David Holmes wrote: >>>>> On 1/04/2020 11:02 am, Yasumasa Suenaga wrote: >>>>>> Thanks Dan and Serguei! >>>>>> >>>>>> I added a comment for this to JDK-8201641. >>>>>> >>>>>> David, can you share Bug ID for thread-to-thread handshake? >>>>>> I want to record it to JDK-8201641 as a blocker. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8240918 >>>>> >>>>> I heard the RFR could be as soon as tomorrow :) >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2020/04/01 1:59, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Yes, this works needs to be done. >>>>>>> I'll take look at you webrev. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 3/31/20 07:41, Daniel D. Daugherty wrote: >>>>>>>> Add Robbin to this thread... >>>>>>>> >>>>>>>> >>>>>>>> This reminded of the following RFE that Robbin filed: >>>>>>>> >>>>>>>> ??? JDK-8201641 JVMTI: GetThreadListStackTraces should use Thread-Local Handshakes >>>>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8201641 >>>>>>>> >>>>>>>> We could update 8201641 to include everything that Yasumasa-san is requesting. >>>>>>>> Would be a good place to track it... >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 2020/03/31 19:16, David Holmes wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Many JVMTI functions uses VM Operation to get information. However some of them need to stop only one thread - they don't need to stop all threads. >>>>>>>>>>> So I think we can use Thread Local Handshake as this webrev. It is example for GetOneCurrentContendedMonitor(). >>>>>>>>>> >>>>>>>>>> True, but at the moment handshakes involve the VMThread. There is work being done to support direct thread-to-thread handshakes and once that is done this kind of conversion should be more easily done. It might be worth waiting for that. >>>>>>>>> >>>>>>>>> Thanks, I will be back to this topic when thread-to-thread handshake is done. >>>>>>>>> I wondered at first why VMThread involves handshake. Its improvement is welcome for me ;) >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>>>>>>> >>>>>>>>>> An observation, it seems to me that calling_thread is not used when this is not a VMOperation. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Also I think we can replace following VM Operations to Thread Local Handshake: >>>>>>>>>>> >>>>>>>>>>> class VM_GetCurrentLocation >>>>>>>>>>> class VM_EnterInterpOnlyMode >>>>>>>>>>> class VM_UpdateForPopTopFrame >>>>>>>>>>> class VM_SetFramePop >>>>>>>>>>> class VM_GetOwnedMonitorInfo >>>>>>>>>>> class VM_GetCurrentContendedMonitor >>>>>>>>>>> class VM_GetFrameCount >>>>>>>>>>> class VM_GetFrameLocation >>>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> It it is acceptable, I will file it to JBS and send review request. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>> >>>>>>> > From serguei.spitsyn at oracle.com Thu Apr 9 06:44:45 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 8 Apr 2020 23:44:45 -0700 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <8ced0d82-4125-7179-bac2-c8ce54807274@oracle.com> <936c63af-cbd0-234a-94e5-5bc03f237b3c@oracle.com> <1bd2bd6f-d51d-d02f-e2df-a4796c2a2d72@oss.nttdata.com> Message-ID: On 4/8/20 23:36, Yasumasa Suenaga wrote: > Thanks David and Serguei! > > I created 3 subtasks under JDK-8201641, of course I will send review > request in each them. > >> ? - GetOneCurrentContendedMonitor => GetCurrentContendedMonitor > > `GetCurrentContendedMonitor` is JVMTI function name, and also it > exists as public member of JvmtiEnv class. > So I want to different name for HandshakeClosure - for example, > GetCurrentContendedMonitorClosure. > > Do you have any idea for it? It is better to follow the same pattern as we already have in other places (until a decision is made about a different rule). So, the GetCurrentContendedMonitorClosure should work for now. It is interesting if there will be any other suggestions though. Thanks, Serguei > > Yasumasa > > > On 2020/04/09 15:19, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> I'm okay with using sub-tasks to do it incrementally. >> >> This needs to be removed with your fix: >> ?? src/hotspot/share/runtime/vmOperations.hpp: >> template(GetCurrentContendedMonitor)??????????? \ >> >> Also, I agree with comments from David below: >> ??- GetOneCurrentContendedMonitor => GetCurrentContendedMonitor >> ??- Thread::current() =>? calling_thread >> >> I hope, you will update the copyright comments in jvmtiEnvBase.?pp. >> >> Are you going to re-post this as an RFR with a correct sub-task number? >> >> Thanks, >> Serguei >> >> >> On 4/8/20 22:52, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 9/04/2020 3:08 pm, Yasumasa Suenaga wrote: >>>> Hi, >>>> >>>> JDK-8240918 has been pushed, so I made a patch for >>>> GetCurrentContendedMonitor(). How about this? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/2/ >>> >>> Generally looks okay. A couple of comments: >>> >>> src/hotspot/share/prims/jvmtiEnv.cpp >>> >>> Please update the comment just before the change: >>> >>> ?? // thread. All other usage needs to use a vm-safepoint-op for >>> safety. >>> >>> --- >>> >>> ?GetOneCurrentContendedMonitor >>> >>> I don't think you need to add One into the name here - the current >>> contended monitor is inherently a singleton. >>> >>> --- >>> >>> src/hotspot/share/prims/jvmtiEnvBase.cpp >>> >>> 655?????????? Thread::current() == java_thread->active_handshaker() || >>> >>> The calling_thread parameter is now the current thread. So this can >>> also be changed: >>> >>> 679???? Handle???? hobj(Thread::current(), obj); >>> >>> >>> >>>>>>>>>>> An observation, it seems to me that calling_thread is not >>>>>>>>>>> used when this is not a VMOperation. >>>> >>>> calling_thread is used for creating JNI reference: >>>> >>>> ``` >>>> *monitor_ptr = jni_reference(calling_thread, hobj); >>>> ``` >>>> >>>> >>>> If it is ok, I will make patches for other JVMTI functions. >>>> However the patch might be bigger, so I want to separate as below. >>>> What do you think? >>>> (I think we can file them as subtask under JDK-8201641) >>>> >>>> >>>> * Monitor operation >>>> ???? - VM_GetOwnedMonitorInfo >>>> ???? - VM_GetCurrentContendedMonitor >>>> >>>> * Frame operation >>>> ???? - VM_UpdateForPopTopFrame >>>> ???? - VM_SetFramePop >>>> >>>> * Thread operation >>>> ???? - VM_GetFrameCount >>>> ???? - VM_GetFrameLocation >>>> ???? - VM_GetThreadListStackTraces >>>> ???? - VM_GetCurrentLocation >>>> ???? - VM_EnterInterpOnlyMode >>> >>> Creating subtasks with separate RFRs is fine by me. It may be good >>> to slowly introduce these changes so that we get some testing >>> coverage to iron out any initial bugs with the approach. >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/04/01 21:29, Yasumasa Suenaga wrote: >>>>> Thanks David! >>>>> >>>>> If JDK-8201641 is not assigned when JDK-8240918 is resolved, I >>>>> will start to work for JDK-8201641. >>>>> (It would be large patch...) >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2020/04/01 19:05, David Holmes wrote: >>>>>> On 1/04/2020 11:02 am, Yasumasa Suenaga wrote: >>>>>>> Thanks Dan and Serguei! >>>>>>> >>>>>>> I added a comment for this to JDK-8201641. >>>>>>> >>>>>>> David, can you share Bug ID for thread-to-thread handshake? >>>>>>> I want to record it to JDK-8201641 as a blocker. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8240918 >>>>>> >>>>>> I heard the RFR could be as soon as tomorrow :) >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2020/04/01 1:59, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> Yes, this works needs to be done. >>>>>>>> I'll take look at you webrev. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> On 3/31/20 07:41, Daniel D. Daugherty wrote: >>>>>>>>> Add Robbin to this thread... >>>>>>>>> >>>>>>>>> >>>>>>>>> This reminded of the following RFE that Robbin filed: >>>>>>>>> >>>>>>>>> ??? JDK-8201641 JVMTI: GetThreadListStackTraces should use >>>>>>>>> Thread-Local Handshakes >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201641 >>>>>>>>> >>>>>>>>> We could update 8201641 to include everything that >>>>>>>>> Yasumasa-san is requesting. >>>>>>>>> Would be a good place to track it... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> On 2020/03/31 19:16, David Holmes wrote: >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Many JVMTI functions uses VM Operation to get information. >>>>>>>>>>>> However some of them need to stop only one thread - they >>>>>>>>>>>> don't need to stop all threads. >>>>>>>>>>>> So I think we can use Thread Local Handshake as this >>>>>>>>>>>> webrev. It is example for GetOneCurrentContendedMonitor(). >>>>>>>>>>> >>>>>>>>>>> True, but at the moment handshakes involve the VMThread. >>>>>>>>>>> There is work being done to support direct thread-to-thread >>>>>>>>>>> handshakes and once that is done this kind of conversion >>>>>>>>>>> should be more easily done. It might be worth waiting for that. >>>>>>>>>> >>>>>>>>>> Thanks, I will be back to this topic when thread-to-thread >>>>>>>>>> handshake is done. >>>>>>>>>> I wondered at first why VMThread involves handshake. Its >>>>>>>>>> improvement is welcome for me ;) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> An observation, it seems to me that calling_thread is not >>>>>>>>>>> used when this is not a VMOperation. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Also I think we can replace following VM Operations to >>>>>>>>>>>> Thread Local Handshake: >>>>>>>>>>>> >>>>>>>>>>>> class VM_GetCurrentLocation >>>>>>>>>>>> class VM_EnterInterpOnlyMode >>>>>>>>>>>> class VM_UpdateForPopTopFrame >>>>>>>>>>>> class VM_SetFramePop >>>>>>>>>>>> class VM_GetOwnedMonitorInfo >>>>>>>>>>>> class VM_GetCurrentContendedMonitor >>>>>>>>>>>> class VM_GetFrameCount >>>>>>>>>>>> class VM_GetFrameLocation >>>>>>>>>>>> >>>>>>>>>>>> What do you think? >>>>>>>>>>>> It it is acceptable, I will file it to JBS and send review >>>>>>>>>>>> request. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>> >> From suenaga at oss.nttdata.com Thu Apr 9 06:52:43 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 9 Apr 2020 15:52:43 +0900 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <8ced0d82-4125-7179-bac2-c8ce54807274@oracle.com> <936c63af-cbd0-234a-94e5-5bc03f237b3c@oracle.com> <1bd2bd6f-d51d-d02f-e2df-a4796c2a2d72@oss.nttdata.com> Message-ID: <2aba2264-f51d-6a07-8c79-aa495829270d@oss.nttdata.com> On 2020/04/09 15:44, serguei.spitsyn at oracle.com wrote: > On 4/8/20 23:36, Yasumasa Suenaga wrote: >> Thanks David and Serguei! >> >> I created 3 subtasks under JDK-8201641, of course I will send review request in each them. >> >>> ? - GetOneCurrentContendedMonitor => GetCurrentContendedMonitor >> >> `GetCurrentContendedMonitor` is JVMTI function name, and also it exists as public member of JvmtiEnv class. >> So I want to different name for HandshakeClosure - for example, GetCurrentContendedMonitorClosure. >> >> Do you have any idea for it? > > It is better to follow the same pattern as we already have in other places (until a decision is made about a different rule). > So, the GetCurrentContendedMonitorClosure should work for now. > It is interesting if there will be any other suggestions though. Currently, most of classes which extend HandshakeClosure have "Closure" as suffix in below: ``` $ grep -nrw HandshakeClosure * | grep -w class share/gc/shenandoah/shenandoahUnload.cpp:161:class ShenandoahUnloadRendezvousClosure : public HandshakeClosure { share/gc/z/zHeap.cpp:333:class ZRendezvousClosure : public HandshakeClosure { share/gc/z/zMark.cpp:422:class ZMarkFlushAndFreeStacksClosure : public HandshakeClosure { share/prims/whitebox.cpp:2046: class TraceSelfClosure : public HandshakeClosure { share/runtime/biasedLocking.cpp:505:class RevokeOneBias : public HandshakeClosure { share/runtime/deoptimization.cpp:808:class DeoptimizeMarkedClosure : public HandshakeClosure { share/runtime/handshake.hpp:44:class HandshakeClosure : public ThreadClosure { share/runtime/sweeper.cpp:200:class NMethodMarkingClosure : public HandshakeClosure { share/runtime/thread.cpp:528:class InstallAsyncExceptionClosure : public HandshakeClosure { share/runtime/vmThread.cpp:391:class HandshakeALotClosure : public HandshakeClosure { ``` I think `GetCurrentContendedMonitorClosure` is not so bad :) Thanks, Yasumasa > Thanks, > Serguei > >> >> Yasumasa >> >> >> On 2020/04/09 15:19, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> I'm okay with using sub-tasks to do it incrementally. >>> >>> This needs to be removed with your fix: >>> ?? src/hotspot/share/runtime/vmOperations.hpp: template(GetCurrentContendedMonitor)??????????? \ >>> >>> Also, I agree with comments from David below: >>> ??- GetOneCurrentContendedMonitor => GetCurrentContendedMonitor >>> ??- Thread::current() =>? calling_thread >>> >>> I hope, you will update the copyright comments in jvmtiEnvBase.?pp. >>> >>> Are you going to re-post this as an RFR with a correct sub-task number? >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/8/20 22:52, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> On 9/04/2020 3:08 pm, Yasumasa Suenaga wrote: >>>>> Hi, >>>>> >>>>> JDK-8240918 has been pushed, so I made a patch for GetCurrentContendedMonitor(). How about this? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/2/ >>>> >>>> Generally looks okay. A couple of comments: >>>> >>>> src/hotspot/share/prims/jvmtiEnv.cpp >>>> >>>> Please update the comment just before the change: >>>> >>>> ?? // thread. All other usage needs to use a vm-safepoint-op for safety. >>>> >>>> --- >>>> >>>> ?GetOneCurrentContendedMonitor >>>> >>>> I don't think you need to add One into the name here - the current contended monitor is inherently a singleton. >>>> >>>> --- >>>> >>>> src/hotspot/share/prims/jvmtiEnvBase.cpp >>>> >>>> 655?????????? Thread::current() == java_thread->active_handshaker() || >>>> >>>> The calling_thread parameter is now the current thread. So this can also be changed: >>>> >>>> 679???? Handle???? hobj(Thread::current(), obj); >>>> >>>> >>>> >>>>>>>>>>>> An observation, it seems to me that calling_thread is not used when this is not a VMOperation. >>>>> >>>>> calling_thread is used for creating JNI reference: >>>>> >>>>> ``` >>>>> *monitor_ptr = jni_reference(calling_thread, hobj); >>>>> ``` >>>>> >>>>> >>>>> If it is ok, I will make patches for other JVMTI functions. >>>>> However the patch might be bigger, so I want to separate as below. What do you think? >>>>> (I think we can file them as subtask under JDK-8201641) >>>>> >>>>> >>>>> * Monitor operation >>>>> ???? - VM_GetOwnedMonitorInfo >>>>> ???? - VM_GetCurrentContendedMonitor >>>>> >>>>> * Frame operation >>>>> ???? - VM_UpdateForPopTopFrame >>>>> ???? - VM_SetFramePop >>>>> >>>>> * Thread operation >>>>> ???? - VM_GetFrameCount >>>>> ???? - VM_GetFrameLocation >>>>> ???? - VM_GetThreadListStackTraces >>>>> ???? - VM_GetCurrentLocation >>>>> ???? - VM_EnterInterpOnlyMode >>>> >>>> Creating subtasks with separate RFRs is fine by me. It may be good to slowly introduce these changes so that we get some testing coverage to iron out any initial bugs with the approach. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2020/04/01 21:29, Yasumasa Suenaga wrote: >>>>>> Thanks David! >>>>>> >>>>>> If JDK-8201641 is not assigned when JDK-8240918 is resolved, I will start to work for JDK-8201641. >>>>>> (It would be large patch...) >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2020/04/01 19:05, David Holmes wrote: >>>>>>> On 1/04/2020 11:02 am, Yasumasa Suenaga wrote: >>>>>>>> Thanks Dan and Serguei! >>>>>>>> >>>>>>>> I added a comment for this to JDK-8201641. >>>>>>>> >>>>>>>> David, can you share Bug ID for thread-to-thread handshake? >>>>>>>> I want to record it to JDK-8201641 as a blocker. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8240918 >>>>>>> >>>>>>> I heard the RFR could be as soon as tomorrow :) >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2020/04/01 1:59, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> Yes, this works needs to be done. >>>>>>>>> I'll take look at you webrev. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> On 3/31/20 07:41, Daniel D. Daugherty wrote: >>>>>>>>>> Add Robbin to this thread... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This reminded of the following RFE that Robbin filed: >>>>>>>>>> >>>>>>>>>> ??? JDK-8201641 JVMTI: GetThreadListStackTraces should use Thread-Local Handshakes >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201641 >>>>>>>>>> >>>>>>>>>> We could update 8201641 to include everything that Yasumasa-san is requesting. >>>>>>>>>> Would be a good place to track it... >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> On 2020/03/31 19:16, David Holmes wrote: >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Many JVMTI functions uses VM Operation to get information. However some of them need to stop only one thread - they don't need to stop all threads. >>>>>>>>>>>>> So I think we can use Thread Local Handshake as this webrev. It is example for GetOneCurrentContendedMonitor(). >>>>>>>>>>>> >>>>>>>>>>>> True, but at the moment handshakes involve the VMThread. There is work being done to support direct thread-to-thread handshakes and once that is done this kind of conversion should be more easily done. It might be worth waiting for that. >>>>>>>>>>> >>>>>>>>>>> Thanks, I will be back to this topic when thread-to-thread handshake is done. >>>>>>>>>>> I wondered at first why VMThread involves handshake. Its improvement is welcome for me ;) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>>>>>>>>> >>>>>>>>>>>> An observation, it seems to me that calling_thread is not used when this is not a VMOperation. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Also I think we can replace following VM Operations to Thread Local Handshake: >>>>>>>>>>>>> >>>>>>>>>>>>> class VM_GetCurrentLocation >>>>>>>>>>>>> class VM_EnterInterpOnlyMode >>>>>>>>>>>>> class VM_UpdateForPopTopFrame >>>>>>>>>>>>> class VM_SetFramePop >>>>>>>>>>>>> class VM_GetOwnedMonitorInfo >>>>>>>>>>>>> class VM_GetCurrentContendedMonitor >>>>>>>>>>>>> class VM_GetFrameCount >>>>>>>>>>>>> class VM_GetFrameLocation >>>>>>>>>>>>> >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> It it is acceptable, I will file it to JBS and send review request. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>> >>> > From robbin.ehn at oracle.com Thu Apr 9 07:03:52 2020 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 9 Apr 2020 09:03:52 +0200 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> Message-ID: <215edb3b-d34c-c0c6-eae0-c433232e306b@oracle.com> Hi, adding the same comment as in the bug regarding GetThreadListStackTraces. Please note that there is a semantic difference taking samples in a safepoint and in handshakes, if there are mutiple thread sampled. With a safepoint; stacktraces are taken from the same exact moment (from a Java mutation perspective). But with handshake we can have mutation between the samples, consider: Thread A enters a mutual exclusive region, and get sampled inside that region. Thread A leaves the mutual exclusive region. Thread B enter the same mutual exclusive region, and get sampled inside that region. When looking at the stack-traces, we have have two thread inside the same mutual exclusive region. If you are not aware on how the sampling mechanism works, this could be confusing. Please verify that we are still following JVM TI specs and at least have information about this change in release notes. Thanks, Robbin On 2020-03-31 16:41, Daniel D. Daugherty wrote: > Add Robbin to this thread... > > > This reminded of the following RFE that Robbin filed: > > ??? JDK-8201641 JVMTI: GetThreadListStackTraces should use Thread-Local > Handshakes > ??? https://bugs.openjdk.java.net/browse/JDK-8201641 > > We could update 8201641 to include everything that Yasumasa-san is > requesting. > Would be a good place to track it... > > Dan > > > On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >> Hi David, >> >> On 2020/03/31 19:16, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Many JVMTI functions uses VM Operation to get information. However >>>> some of them need to stop only one thread - they don't need to stop >>>> all threads. >>>> So I think we can use Thread Local Handshake as this webrev. It is >>>> example for GetOneCurrentContendedMonitor(). >>> >>> True, but at the moment handshakes involve the VMThread. There is >>> work being done to support direct thread-to-thread handshakes and >>> once that is done this kind of conversion should be more easily done. >>> It might be worth waiting for that. >> >> Thanks, I will be back to this topic when thread-to-thread handshake >> is done. >> I wondered at first why VMThread involves handshake. Its improvement >> is welcome for me ;) >> >> >> Cheers, >> >> Yasumasa >> >> >>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>> >>> An observation, it seems to me that calling_thread is not used when >>> this is not a VMOperation. >>> >>> Cheers, >>> David >>> >>>> Also I think we can replace following VM Operations to Thread Local >>>> Handshake: >>>> >>>> class VM_GetCurrentLocation >>>> class VM_EnterInterpOnlyMode >>>> class VM_UpdateForPopTopFrame >>>> class VM_SetFramePop >>>> class VM_GetOwnedMonitorInfo >>>> class VM_GetCurrentContendedMonitor >>>> class VM_GetFrameCount >>>> class VM_GetFrameLocation >>>> >>>> What do you think? >>>> It it is acceptable, I will file it to JBS and send review request. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa > From suenaga at oss.nttdata.com Thu Apr 9 07:12:28 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 9 Apr 2020 16:12:28 +0900 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: <215edb3b-d34c-c0c6-eae0-c433232e306b@oracle.com> References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <215edb3b-d34c-c0c6-eae0-c433232e306b@oracle.com> Message-ID: Hi Robbin, I think we can change GetThreadListStackTrace(VM_GetThreadListStackTraces) if the caller requests only 1 thread stack (thread_count == 1). It does not break JVMTI spec. In other case, we should use safepoint (VM Operation) for following JVMTI spec: ``` All stacks are collected simultaneously, that is, no changes will occur to the thread state or stacks between the sampling one thread and the next. The threads need not be suspended. ``` Thus I think we don't need describe release notes about it. Thanks, Yasumasa On 2020/04/09 16:03, Robbin Ehn wrote: > Hi, adding the same comment as in the bug regarding GetThreadListStackTraces. > > Please note that there is a semantic difference taking samples in a > safepoint and in handshakes, if there are mutiple thread sampled. > With a safepoint; stacktraces are taken from the same exact moment (from > a Java mutation perspective). > > But with handshake we can have mutation between the samples, consider: > Thread A enters a mutual exclusive region, and get sampled inside that > region. > Thread A leaves the mutual exclusive region. > Thread B enter the same mutual exclusive region, and get sampled inside that region. > > When looking at the stack-traces, we have have two thread inside the same mutual exclusive region. > If you are not aware on how the sampling mechanism works, this could be confusing. > > Please verify that we are still following JVM TI specs and at least have > information about this change in release notes. > > Thanks, Robbin > > On 2020-03-31 16:41, Daniel D. Daugherty wrote: >> Add Robbin to this thread... >> >> >> This reminded of the following RFE that Robbin filed: >> >> ???? JDK-8201641 JVMTI: GetThreadListStackTraces should use Thread-Local Handshakes >> ???? https://bugs.openjdk.java.net/browse/JDK-8201641 >> >> We could update 8201641 to include everything that Yasumasa-san is requesting. >> Would be a good place to track it... >> >> Dan >> >> >> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> On 2020/03/31 19:16, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Many JVMTI functions uses VM Operation to get information. However some of them need to stop only one thread - they don't need to stop all threads. >>>>> So I think we can use Thread Local Handshake as this webrev. It is example for GetOneCurrentContendedMonitor(). >>>> >>>> True, but at the moment handshakes involve the VMThread. There is work being done to support direct thread-to-thread handshakes and once that is done this kind of conversion should be more easily done. It might be worth waiting for that. >>> >>> Thanks, I will be back to this topic when thread-to-thread handshake is done. >>> I wondered at first why VMThread involves handshake. Its improvement is welcome for me ;) >>> >>> >>> Cheers, >>> >>> Yasumasa >>> >>> >>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>> >>>> An observation, it seems to me that calling_thread is not used when this is not a VMOperation. >>>> >>>> Cheers, >>>> David >>>> >>>>> Also I think we can replace following VM Operations to Thread Local Handshake: >>>>> >>>>> class VM_GetCurrentLocation >>>>> class VM_EnterInterpOnlyMode >>>>> class VM_UpdateForPopTopFrame >>>>> class VM_SetFramePop >>>>> class VM_GetOwnedMonitorInfo >>>>> class VM_GetCurrentContendedMonitor >>>>> class VM_GetFrameCount >>>>> class VM_GetFrameLocation >>>>> >>>>> What do you think? >>>>> It it is acceptable, I will file it to JBS and send review request. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >> From robbin.ehn at oracle.com Thu Apr 9 07:19:23 2020 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 9 Apr 2020 09:19:23 +0200 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <215edb3b-d34c-c0c6-eae0-c433232e306b@oracle.com> Message-ID: <3b203cfc-f9bc-2826-9e9e-745fd5d2baf9@oracle.com> Hi Yasumasa, We have had internal requests doing GetThreadListStackTraces with multiple threads with handshakes. Since you can sample hundreds of times per second using handshakes with little interference with your application. The internal request sampled all threads ~10 times per second. So they very much would like the performance instead of the 'precision'. Is if it's deemed feasible to always use handshakes we should consider it. Thanks, Robbin On 2020-04-09 09:12, Yasumasa Suenaga wrote: > Hi Robbin, > > I think we can change > GetThreadListStackTrace(VM_GetThreadListStackTraces) if the caller > requests only 1 thread stack (thread_count == 1). It does not break > JVMTI spec. > In other case, we should use safepoint (VM Operation) for following > JVMTI spec: > > ``` > All stacks are collected simultaneously, that is, no changes will occur > to the thread state or stacks between the sampling one thread and the > next. The threads need not be suspended. > ``` > > Thus I think we don't need describe release notes about it. > > > Thanks, > > Yasumasa > > > On 2020/04/09 16:03, Robbin Ehn wrote: >> Hi, adding the same comment as in the bug regarding >> GetThreadListStackTraces. >> >> Please note that there is a semantic difference taking samples in a >> safepoint and in handshakes, if there are mutiple thread sampled. >> With a safepoint; stacktraces are taken from the same exact moment (from >> a Java mutation perspective). >> >> But with handshake we can have mutation between the samples, consider: >> Thread A enters a mutual exclusive region, and get sampled inside that >> region. >> Thread A leaves the mutual exclusive region. >> Thread B enter the same mutual exclusive region, and get sampled >> inside that region. >> >> When looking at the stack-traces, we have have two thread inside the >> same mutual exclusive region. >> If you are not aware on how the sampling mechanism works, this could >> be confusing. >> >> Please verify that we are still following JVM TI specs and at least have >> information about this change in release notes. >> >> Thanks, Robbin >> >> On 2020-03-31 16:41, Daniel D. Daugherty wrote: >>> Add Robbin to this thread... >>> >>> >>> This reminded of the following RFE that Robbin filed: >>> >>> ???? JDK-8201641 JVMTI: GetThreadListStackTraces should use >>> Thread-Local Handshakes >>> ???? https://bugs.openjdk.java.net/browse/JDK-8201641 >>> >>> We could update 8201641 to include everything that Yasumasa-san is >>> requesting. >>> Would be a good place to track it... >>> >>> Dan >>> >>> >>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> On 2020/03/31 19:16, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Many JVMTI functions uses VM Operation to get information. However >>>>>> some of them need to stop only one thread - they don't need to >>>>>> stop all threads. >>>>>> So I think we can use Thread Local Handshake as this webrev. It is >>>>>> example for GetOneCurrentContendedMonitor(). >>>>> >>>>> True, but at the moment handshakes involve the VMThread. There is >>>>> work being done to support direct thread-to-thread handshakes and >>>>> once that is done this kind of conversion should be more easily >>>>> done. It might be worth waiting for that. >>>> >>>> Thanks, I will be back to this topic when thread-to-thread handshake >>>> is done. >>>> I wondered at first why VMThread involves handshake. Its improvement >>>> is welcome for me ;) >>>> >>>> >>>> Cheers, >>>> >>>> Yasumasa >>>> >>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>> >>>>> An observation, it seems to me that calling_thread is not used when >>>>> this is not a VMOperation. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Also I think we can replace following VM Operations to Thread >>>>>> Local Handshake: >>>>>> >>>>>> class VM_GetCurrentLocation >>>>>> class VM_EnterInterpOnlyMode >>>>>> class VM_UpdateForPopTopFrame >>>>>> class VM_SetFramePop >>>>>> class VM_GetOwnedMonitorInfo >>>>>> class VM_GetCurrentContendedMonitor >>>>>> class VM_GetFrameCount >>>>>> class VM_GetFrameLocation >>>>>> >>>>>> What do you think? >>>>>> It it is acceptable, I will file it to JBS and send review request. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>> From suenaga at oss.nttdata.com Thu Apr 9 07:39:07 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 9 Apr 2020 16:39:07 +0900 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: <3b203cfc-f9bc-2826-9e9e-745fd5d2baf9@oracle.com> References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <215edb3b-d34c-c0c6-eae0-c433232e306b@oracle.com> <3b203cfc-f9bc-2826-9e9e-745fd5d2baf9@oracle.com> Message-ID: On 2020/04/09 16:19, Robbin Ehn wrote: > Hi Yasumasa, > > We have had internal requests doing GetThreadListStackTraces with > multiple threads with handshakes. Since you can sample hundreds of times > per second using handshakes with little interference with your > application. > The internal request sampled all threads ~10 times per second. > So they very much would like the performance instead of the 'precision'. Hmm, it seems to violate the spec of GetThreadListStackTraces(): https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#GetThreadListStackTraces ``` All stacks are collected simultaneously, that is, no changes will occur to the thread state or stacks between the sampling one thread and the next. ``` So I think this ticket (JDK-8242428) should just support Thread-Local Handshakes when thread_count == 1. For other case, we should introduce other API because current spec of GetThreadListStackTraces() is useful for some case IMHO. For example, the profiler detects some threads which have much CPU time, we can gather stack traces of them. We don't need to choose threads from all thread dump. Of course, Both GetThreadListStackTraces() and GetAllStackTrace() use safepoint, but GetThreadListStackTraces() is useful interface for profiler developers. Thus I think the spec of GetThreadListStackTraces() should not be changed. Thanks, Yasumasa > Is if it's deemed feasible to always use handshakes we should consider it. > > Thanks, Robbin > > On 2020-04-09 09:12, Yasumasa Suenaga wrote: >> Hi Robbin, >> >> I think we can change GetThreadListStackTrace(VM_GetThreadListStackTraces) if the caller requests only 1 thread stack (thread_count == 1). It does not break JVMTI spec. >> In other case, we should use safepoint (VM Operation) for following JVMTI spec: >> >> ``` >> All stacks are collected simultaneously, that is, no changes will occur to the thread state or stacks between the sampling one thread and the next. The threads need not be suspended. >> ``` >> >> Thus I think we don't need describe release notes about it. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/09 16:03, Robbin Ehn wrote: >>> Hi, adding the same comment as in the bug regarding GetThreadListStackTraces. >>> >>> Please note that there is a semantic difference taking samples in a >>> safepoint and in handshakes, if there are mutiple thread sampled. >>> With a safepoint; stacktraces are taken from the same exact moment (from >>> a Java mutation perspective). >>> >>> But with handshake we can have mutation between the samples, consider: >>> Thread A enters a mutual exclusive region, and get sampled inside that >>> region. >>> Thread A leaves the mutual exclusive region. >>> Thread B enter the same mutual exclusive region, and get sampled inside that region. >>> >>> When looking at the stack-traces, we have have two thread inside the same mutual exclusive region. >>> If you are not aware on how the sampling mechanism works, this could be confusing. >>> >>> Please verify that we are still following JVM TI specs and at least have >>> information about this change in release notes. >>> >>> Thanks, Robbin >>> >>> On 2020-03-31 16:41, Daniel D. Daugherty wrote: >>>> Add Robbin to this thread... >>>> >>>> >>>> This reminded of the following RFE that Robbin filed: >>>> >>>> ???? JDK-8201641 JVMTI: GetThreadListStackTraces should use Thread-Local Handshakes >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8201641 >>>> >>>> We could update 8201641 to include everything that Yasumasa-san is requesting. >>>> Would be a good place to track it... >>>> >>>> Dan >>>> >>>> >>>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> On 2020/03/31 19:16, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Many JVMTI functions uses VM Operation to get information. However some of them need to stop only one thread - they don't need to stop all threads. >>>>>>> So I think we can use Thread Local Handshake as this webrev. It is example for GetOneCurrentContendedMonitor(). >>>>>> >>>>>> True, but at the moment handshakes involve the VMThread. There is work being done to support direct thread-to-thread handshakes and once that is done this kind of conversion should be more easily done. It might be worth waiting for that. >>>>> >>>>> Thanks, I will be back to this topic when thread-to-thread handshake is done. >>>>> I wondered at first why VMThread involves handshake. Its improvement is welcome for me ;) >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>>> >>>>>> An observation, it seems to me that calling_thread is not used when this is not a VMOperation. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> Also I think we can replace following VM Operations to Thread Local Handshake: >>>>>>> >>>>>>> class VM_GetCurrentLocation >>>>>>> class VM_EnterInterpOnlyMode >>>>>>> class VM_UpdateForPopTopFrame >>>>>>> class VM_SetFramePop >>>>>>> class VM_GetOwnedMonitorInfo >>>>>>> class VM_GetCurrentContendedMonitor >>>>>>> class VM_GetFrameCount >>>>>>> class VM_GetFrameLocation >>>>>>> >>>>>>> What do you think? >>>>>>> It it is acceptable, I will file it to JBS and send review request. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>> From robbin.ehn at oracle.com Thu Apr 9 07:40:59 2020 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 9 Apr 2020 09:40:59 +0200 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <215edb3b-d34c-c0c6-eae0-c433232e306b@oracle.com> <3b203cfc-f9bc-2826-9e9e-745fd5d2baf9@oracle.com> Message-ID: Ok, thanks for looking into it! /Robbin On 2020-04-09 09:39, Yasumasa Suenaga wrote: > On 2020/04/09 16:19, Robbin Ehn wrote: >> Hi Yasumasa, >> >> We have had internal requests doing GetThreadListStackTraces with >> multiple threads with handshakes. Since you can sample hundreds of times >> per second using handshakes with little interference with your >> application. >> The internal request sampled all threads ~10 times per second. >> So they very much would like the performance instead of the 'precision'. > > Hmm, it seems to violate the spec of GetThreadListStackTraces(): > > https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#GetThreadListStackTraces > > ``` > All stacks are collected simultaneously, that is, no changes will occur > to the thread state or stacks between the sampling one thread and the next. > ``` > > So I think this ticket (JDK-8242428) should just support Thread-Local > Handshakes when thread_count == 1. > For other case, we should introduce other API because current spec of > GetThreadListStackTraces() is useful for some case IMHO. > > For example, the profiler detects some threads which have much CPU time, > we can gather stack traces of them. We don't need to choose threads from > all thread dump. > Of course, Both GetThreadListStackTraces() and GetAllStackTrace() use > safepoint, but GetThreadListStackTraces() is useful interface for > profiler developers. Thus I think the spec of GetThreadListStackTraces() > should not be changed. > > > Thanks, > > Yasumasa > > >> Is if it's deemed feasible to always use handshakes we should consider >> it. >> >> Thanks, Robbin >> >> On 2020-04-09 09:12, Yasumasa Suenaga wrote: >>> Hi Robbin, >>> >>> I think we can change >>> GetThreadListStackTrace(VM_GetThreadListStackTraces) if the caller >>> requests only 1 thread stack (thread_count == 1). It does not break >>> JVMTI spec. >>> In other case, we should use safepoint (VM Operation) for following >>> JVMTI spec: >>> >>> ``` >>> All stacks are collected simultaneously, that is, no changes will >>> occur to the thread state or stacks between the sampling one thread >>> and the next. The threads need not be suspended. >>> ``` >>> >>> Thus I think we don't need describe release notes about it. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/04/09 16:03, Robbin Ehn wrote: >>>> Hi, adding the same comment as in the bug regarding >>>> GetThreadListStackTraces. >>>> >>>> Please note that there is a semantic difference taking samples in a >>>> safepoint and in handshakes, if there are mutiple thread sampled. >>>> With a safepoint; stacktraces are taken from the same exact moment >>>> (from >>>> a Java mutation perspective). >>>> >>>> But with handshake we can have mutation between the samples, consider: >>>> Thread A enters a mutual exclusive region, and get sampled inside that >>>> region. >>>> Thread A leaves the mutual exclusive region. >>>> Thread B enter the same mutual exclusive region, and get sampled >>>> inside that region. >>>> >>>> When looking at the stack-traces, we have have two thread inside the >>>> same mutual exclusive region. >>>> If you are not aware on how the sampling mechanism works, this could >>>> be confusing. >>>> >>>> Please verify that we are still following JVM TI specs and at least >>>> have >>>> information about this change in release notes. >>>> >>>> Thanks, Robbin >>>> >>>> On 2020-03-31 16:41, Daniel D. Daugherty wrote: >>>>> Add Robbin to this thread... >>>>> >>>>> >>>>> This reminded of the following RFE that Robbin filed: >>>>> >>>>> ???? JDK-8201641 JVMTI: GetThreadListStackTraces should use >>>>> Thread-Local Handshakes >>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8201641 >>>>> >>>>> We could update 8201641 to include everything that Yasumasa-san is >>>>> requesting. >>>>> Would be a good place to track it... >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> On 2020/03/31 19:16, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Many JVMTI functions uses VM Operation to get information. >>>>>>>> However some of them need to stop only one thread - they don't >>>>>>>> need to stop all threads. >>>>>>>> So I think we can use Thread Local Handshake as this webrev. It >>>>>>>> is example for GetOneCurrentContendedMonitor(). >>>>>>> >>>>>>> True, but at the moment handshakes involve the VMThread. There is >>>>>>> work being done to support direct thread-to-thread handshakes and >>>>>>> once that is done this kind of conversion should be more easily >>>>>>> done. It might be worth waiting for that. >>>>>> >>>>>> Thanks, I will be back to this topic when thread-to-thread >>>>>> handshake is done. >>>>>> I wondered at first why VMThread involves handshake. Its >>>>>> improvement is welcome for me ;) >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>>>> >>>>>>> An observation, it seems to me that calling_thread is not used >>>>>>> when this is not a VMOperation. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> Also I think we can replace following VM Operations to Thread >>>>>>>> Local Handshake: >>>>>>>> >>>>>>>> class VM_GetCurrentLocation >>>>>>>> class VM_EnterInterpOnlyMode >>>>>>>> class VM_UpdateForPopTopFrame >>>>>>>> class VM_SetFramePop >>>>>>>> class VM_GetOwnedMonitorInfo >>>>>>>> class VM_GetCurrentContendedMonitor >>>>>>>> class VM_GetFrameCount >>>>>>>> class VM_GetFrameLocation >>>>>>>> >>>>>>>> What do you think? >>>>>>>> It it is acceptable, I will file it to JBS and send review request. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>> From daniil.x.titov at oracle.com Thu Apr 9 07:45:17 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 09 Apr 2020 00:45:17 -0700 Subject: RFR 8242430: Correct links in javadoc of OperatingSystemMXBean Message-ID: <22D902AC-A171-45C3-BAD0-E0326B5389B9@oracle.com> Please review a javadoc fix [1] that corrects the links in the description of getTotalPhysicalMemorySize() method in com.sun.management. OperatingSystemMXBean class. The CSR [2] needs a reviewer as well. [1] Webrev: http://cr.openjdk.java.net/~dtitov/8242430/webrev.01/ [2] CSR: https://bugs.openjdk.java.net/browse/JDK-8242431 [3] Bug: https://bugs.openjdk.java.net/browse/JDK-8242430 Thank you, Daniil From david.holmes at oracle.com Thu Apr 9 09:56:53 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Apr 2020 19:56:53 +1000 Subject: RFR 8242430: Correct links in javadoc of OperatingSystemMXBean In-Reply-To: <22D902AC-A171-45C3-BAD0-E0326B5389B9@oracle.com> References: <22D902AC-A171-45C3-BAD0-E0326B5389B9@oracle.com> Message-ID: <20a20f8c-f73f-cbaf-3002-0c4df8bafeb6@oracle.com> On 9/04/2020 5:45 pm, Daniil Titov wrote: > Please review a javadoc fix [1] that corrects the links in the description of getTotalPhysicalMemorySize() > method in com.sun.management. OperatingSystemMXBean class. The CSR [2] needs a reviewer as well. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8242430/webrev.01/ > [2] CSR: https://bugs.openjdk.java.net/browse/JDK-8242431 > [3] Bug: https://bugs.openjdk.java.net/browse/JDK-8242430 Wow that is severely embarrassing. How on earth did we all miss this mistake? :( Fix looks good. Thanks, David > Thank you, > Daniil > > From david.holmes at oracle.com Thu Apr 9 10:16:24 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Apr 2020 20:16:24 +1000 Subject: Thread Local Handshake in JVMTI functions In-Reply-To: References: <9ecf6856-f5c7-4723-7cc9-7d257e7bb7c0@oss.nttdata.com> <4c9aa3ab-468d-eede-18f7-ac8d352575b6@oss.nttdata.com> <64323780-b96e-0e3a-5f61-8f1dd74a1805@oracle.com> <215edb3b-d34c-c0c6-eae0-c433232e306b@oracle.com> <3b203cfc-f9bc-2826-9e9e-745fd5d2baf9@oracle.com> Message-ID: <96b0d7c3-2d7e-4bb6-83cc-f184f18410c2@oracle.com> On 9/04/2020 5:39 pm, Yasumasa Suenaga wrote: > On 2020/04/09 16:19, Robbin Ehn wrote: >> Hi Yasumasa, >> >> We have had internal requests doing GetThreadListStackTraces with >> multiple threads with handshakes. Since you can sample hundreds of times >> per second using handshakes with little interference with your >> application. >> The internal request sampled all threads ~10 times per second. >> So they very much would like the performance instead of the 'precision'. Well they won't get it with this particular API :) If they don't want precision then they can workaround by iterating the threads themselves and requesting one stacktrace at a time. It won't be quite as performant of course, but probably better than current safepoint approach. > Hmm, it seems to violate the spec of GetThreadListStackTraces(): > > https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#GetThreadListStackTraces > > ``` > All stacks are collected simultaneously, that is, no changes will occur > to the thread state or stacks between the sampling one thread and the next. > ``` > > So I think this ticket (JDK-8242428) should just support Thread-Local > Handshakes when thread_count == 1. Yes. > For other case, we should introduce other API because current spec of > GetThreadListStackTraces() is useful for some case IMHO. The current spec is critical for debugging, and can't be changed regardless. A new API would be needed to get non-simultaneous stacks. Cheers, David ----- > For example, the profiler detects some threads which have much CPU time, > we can gather stack traces of them. We don't need to choose threads from > all thread dump. > Of course, Both GetThreadListStackTraces() and GetAllStackTrace() use > safepoint, but GetThreadListStackTraces() is useful interface for > profiler developers. Thus I think the spec of GetThreadListStackTraces() > should not be changed. > > > Thanks, > > Yasumasa > > >> Is if it's deemed feasible to always use handshakes we should consider >> it. >> >> Thanks, Robbin >> >> On 2020-04-09 09:12, Yasumasa Suenaga wrote: >>> Hi Robbin, >>> >>> I think we can change >>> GetThreadListStackTrace(VM_GetThreadListStackTraces) if the caller >>> requests only 1 thread stack (thread_count == 1). It does not break >>> JVMTI spec. >>> In other case, we should use safepoint (VM Operation) for following >>> JVMTI spec: >>> >>> ``` >>> All stacks are collected simultaneously, that is, no changes will >>> occur to the thread state or stacks between the sampling one thread >>> and the next. The threads need not be suspended. >>> ``` >>> >>> Thus I think we don't need describe release notes about it. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/04/09 16:03, Robbin Ehn wrote: >>>> Hi, adding the same comment as in the bug regarding >>>> GetThreadListStackTraces. >>>> >>>> Please note that there is a semantic difference taking samples in a >>>> safepoint and in handshakes, if there are mutiple thread sampled. >>>> With a safepoint; stacktraces are taken from the same exact moment >>>> (from >>>> a Java mutation perspective). >>>> >>>> But with handshake we can have mutation between the samples, consider: >>>> Thread A enters a mutual exclusive region, and get sampled inside that >>>> region. >>>> Thread A leaves the mutual exclusive region. >>>> Thread B enter the same mutual exclusive region, and get sampled >>>> inside that region. >>>> >>>> When looking at the stack-traces, we have have two thread inside the >>>> same mutual exclusive region. >>>> If you are not aware on how the sampling mechanism works, this could >>>> be confusing. >>>> >>>> Please verify that we are still following JVM TI specs and at least >>>> have >>>> information about this change in release notes. >>>> >>>> Thanks, Robbin >>>> >>>> On 2020-03-31 16:41, Daniel D. Daugherty wrote: >>>>> Add Robbin to this thread... >>>>> >>>>> >>>>> This reminded of the following RFE that Robbin filed: >>>>> >>>>> ???? JDK-8201641 JVMTI: GetThreadListStackTraces should use >>>>> Thread-Local Handshakes >>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8201641 >>>>> >>>>> We could update 8201641 to include everything that Yasumasa-san is >>>>> requesting. >>>>> Would be a good place to track it... >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 3/31/20 7:40 AM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> On 2020/03/31 19:16, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Many JVMTI functions uses VM Operation to get information. >>>>>>>> However some of them need to stop only one thread - they don't >>>>>>>> need to stop all threads. >>>>>>>> So I think we can use Thread Local Handshake as this webrev. It >>>>>>>> is example for GetOneCurrentContendedMonitor(). >>>>>>> >>>>>>> True, but at the moment handshakes involve the VMThread. There is >>>>>>> work being done to support direct thread-to-thread handshakes and >>>>>>> once that is done this kind of conversion should be more easily >>>>>>> done. It might be worth waiting for that. >>>>>> >>>>>> Thanks, I will be back to this topic when thread-to-thread >>>>>> handshake is done. >>>>>> I wondered at first why VMThread involves handshake. Its >>>>>> improvement is welcome for me ;) >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ >>>>>>> >>>>>>> An observation, it seems to me that calling_thread is not used >>>>>>> when this is not a VMOperation. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> Also I think we can replace following VM Operations to Thread >>>>>>>> Local Handshake: >>>>>>>> >>>>>>>> class VM_GetCurrentLocation >>>>>>>> class VM_EnterInterpOnlyMode >>>>>>>> class VM_UpdateForPopTopFrame >>>>>>>> class VM_SetFramePop >>>>>>>> class VM_GetOwnedMonitorInfo >>>>>>>> class VM_GetCurrentContendedMonitor >>>>>>>> class VM_GetFrameCount >>>>>>>> class VM_GetFrameLocation >>>>>>>> >>>>>>>> What do you think? >>>>>>>> It it is acceptable, I will file it to JBS and send review request. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>> From daniel.daugherty at oracle.com Thu Apr 9 13:34:30 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 9 Apr 2020 09:34:30 -0400 Subject: RFR (XS): 8242241: add assert to ClassUnloadEventImpl::className In-Reply-To: <6c66916f-ccdf-6d16-ae98-a20eea48b7fe@oracle.com> References: <6c66916f-ccdf-6d16-ae98-a20eea48b7fe@oracle.com> Message-ID: <2fa4848e-c549-abb5-9a34-1b5fa4ab0dc9@oracle.com> On 4/7/20 6:39 PM, serguei.spitsyn at oracle.com wrote: > Please, review a fix for minor JDI enhancement: > https://bugs.openjdk.java.net/browse/JDK-8242241 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/8242241-jdi-add-assert.1/ src/jdk.jdi/share/classes/com/sun/tools/jdi/EventSetImpl.java ??? No comments. Thumbs up. You could have sent this one out as an "RFR(T)" review, but now you have a second review. Dan > > Summary: > ? A useful assert is introduced to check the class signature format is > correct. > > Testing: > ? The mach5 tier5 results are good. > > Thanks, > Serguei > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Apr 9 14:26:00 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 Apr 2020 07:26:00 -0700 Subject: RFR (XS): 8242241: add assert to ClassUnloadEventImpl::className In-Reply-To: <2fa4848e-c549-abb5-9a34-1b5fa4ab0dc9@oracle.com> References: <6c66916f-ccdf-6d16-ae98-a20eea48b7fe@oracle.com> <2fa4848e-c549-abb5-9a34-1b5fa4ab0dc9@oracle.com> Message-ID: Thanks you, Dan! Serguei On 4/9/20 06:34, Daniel D. Daugherty wrote: > On 4/7/20 6:39 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for minor JDI enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8242241 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/8242241-jdi-add-assert.1/ > > src/jdk.jdi/share/classes/com/sun/tools/jdi/EventSetImpl.java > ??? No comments. > > Thumbs up. You could have sent this one out as an "RFR(T)" review, but > now you have a second review. > > Dan > > >> >> Summary: >> ? A useful assert is introduced to check the class signature format >> is correct. >> >> Testing: >> ? The mach5 tier5 results are good. >> >> Thanks, >> Serguei >> >> >> > From chris.plummer at oracle.com Thu Apr 9 15:57:49 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 9 Apr 2020 08:57:49 -0700 Subject: RFR(T) 8184249: SA: clhsdb 'intConstant' throws a NullPointerException when not attached to a VM Message-ID: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8184249 http://cr.openjdk.java.net/~cjplummer/8184249/webrev.00/index.html Details are in the CR. I'd like to consider this fix as trivial, and have also added the noreg-trivial label to the CR since there is no test case for it. thanks, Chris From alexey.menkov at oracle.com Thu Apr 9 20:42:51 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 9 Apr 2020 13:42:51 -0700 Subject: RFR: JDK-8242282: Test sun/tools/jps/TestJps.java fails after JDK-8237572 Message-ID: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> Hi all, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8242282 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev/ The test creates jar with test classes and run it with "java -jar ". The problem is single "@run Test" tag is executed by JTreg inconsistently - sometimes library classes are compiled to test directory, sometimes - to library directory. The fix explicitly forces required library classes compilation (so library files are compiled to library dir) and add classpath directories to jar manifest. --alex From alexey.menkov at oracle.com Thu Apr 9 20:47:45 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 9 Apr 2020 13:47:45 -0700 Subject: RFR(T) 8184249: SA: clhsdb 'intConstant' throws a NullPointerException when not attached to a VM In-Reply-To: References: Message-ID: <74b79bfd-ad20-d462-9d39-1311a511ac61@oracle.com> Hi Chris, Looks good and trivial. --alex On 04/09/2020 08:57, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8184249 > http://cr.openjdk.java.net/~cjplummer/8184249/webrev.00/index.html > > Details are in the CR. I'd like to consider this fix as trivial, and > have also added the noreg-trivial label to the CR since there is no test > case for it. > > thanks, > > Chris From daniel.daugherty at oracle.com Thu Apr 9 21:01:41 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 9 Apr 2020 17:01:41 -0400 Subject: RFR: JDK-8242282: Test sun/tools/jps/TestJps.java fails after JDK-8237572 In-Reply-To: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> References: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> Message-ID: <7c820d26-e3ae-3ec7-b05d-c7fcaa0b8668@oracle.com> On 4/9/20 4:42 PM, Alex Menkov wrote: > Hi all, > > Please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8242282 > webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev/ test/jdk/sun/tools/jps/LingeredAppForJps.java ??? L89: ??????????????? manifestClasspath += " " + new File(path ).toURI(); ??????? nit - please delete extra space before ')'. ??? old L91: ????????????? break; ??????? So the old version only added the first existing file found in the ??????? path to the jarArgs. The new version is added all existing files. ??????? Maybe I misread the bug report, but I didn't think you wanted to ??????? do that. ??????? Also, can you provide an example of the old manifest file versus the ??????? new manifest file after this change? test/jdk/sun/tools/jps/TestJps.java ??? No comments. > > The test creates jar with test classes and run it with "java -jar > ". > The problem is single "@run Test" tag is executed by JTreg > inconsistently - sometimes library classes are compiled to test > directory, sometimes - to library directory. > The fix explicitly forces required library classes compilation (so > library files are compiled to library dir) and add classpath > directories to jar manifest. This description doesn't mention jar'ing up additional files so you can see my confusion (I hope). Dan > > --alex From daniel.daugherty at oracle.com Thu Apr 9 21:04:02 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 9 Apr 2020 17:04:02 -0400 Subject: RFR: JDK-8242282: Test sun/tools/jps/TestJps.java fails after JDK-8237572 In-Reply-To: <7c820d26-e3ae-3ec7-b05d-c7fcaa0b8668@oracle.com> References: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> <7c820d26-e3ae-3ec7-b05d-c7fcaa0b8668@oracle.com> Message-ID: <41246e47-b358-2ab1-1976-6df8ab32229f@oracle.com> Sorry, pressed "send" too soon. There's no information on how this fix was tested. Right now we're seeing a varying number of failures in almost every Tier5 CI job set. Please verify that you've tested Tier5. Dan On 4/9/20 5:01 PM, Daniel D. Daugherty wrote: > On 4/9/20 4:42 PM, Alex Menkov wrote: >> Hi all, >> >> Please review the fix for >> https://bugs.openjdk.java.net/browse/JDK-8242282 >> webrev: >> http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev/ > > test/jdk/sun/tools/jps/LingeredAppForJps.java > ??? L89: ??????????????? manifestClasspath += " " + new File(path > ).toURI(); > ??????? nit - please delete extra space before ')'. > > ??? old L91: ????????????? break; > ??????? So the old version only added the first existing file found in > the > ??????? path to the jarArgs. The new version is added all existing files. > ??????? Maybe I misread the bug report, but I didn't think you wanted to > ??????? do that. > > ??????? Also, can you provide an example of the old manifest file > versus the > ??????? new manifest file after this change? > > test/jdk/sun/tools/jps/TestJps.java > ??? No comments. > >> >> The test creates jar with test classes and run it with "java -jar >> ". >> The problem is single "@run Test" tag is executed by JTreg >> inconsistently - sometimes library classes are compiled to test >> directory, sometimes - to library directory. >> The fix explicitly forces required library classes compilation (so >> library files are compiled to library dir) and add classpath >> directories to jar manifest. > > This description doesn't mention jar'ing up additional files so you > can see > my confusion (I hope). > > Dan > > >> >> --alex > From alexey.menkov at oracle.com Thu Apr 9 21:15:48 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 9 Apr 2020 14:15:48 -0700 Subject: RFR: JDK-8242282: Test sun/tools/jps/TestJps.java fails after JDK-8237572 In-Reply-To: <7c820d26-e3ae-3ec7-b05d-c7fcaa0b8668@oracle.com> References: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> <7c820d26-e3ae-3ec7-b05d-c7fcaa0b8668@oracle.com> Message-ID: On 04/09/2020 14:01, Daniel D. Daugherty wrote: > On 4/9/20 4:42 PM, Alex Menkov wrote: >> Hi all, >> >> Please review the fix for >> https://bugs.openjdk.java.net/browse/JDK-8242282 >> webrev: >> http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev/ > > test/jdk/sun/tools/jps/LingeredAppForJps.java > ??? L89: ??????????????? manifestClasspath += " " + new File(path > ).toURI(); > ??????? nit - please delete extra space before ')'. Done locally. > > ??? old L91: ????????????? break; > ??????? So the old version only added the first existing file found in the > ??????? path to the jarArgs. The new version is added all existing files. > ??????? Maybe I misread the bug report, but I didn't think you wanted to > ??????? do that. The idea of the code is to add to jar only files from test class directory and don't add files from any other classpath dirs. With the fix all other classpath dirs are added to manifest "Class-Path". > > ??????? Also, can you provide an example of the old manifest file > versus the > ??????? new manifest file after this change? in my env old manifest.mf (generated): =================== Main-Class: LingeredAppForJps =================== new one: =================== Main-Class: LingeredAppForJps Class-Path: file:/D:/ade/jvm/hs_4/build/windows-x64-debug/test-support/jtreg_open_test_jdk_sun_tools_jps/classes/0/test/lib/ =================== old manifest from generated .jar: =================== Manifest-Version: 1.0 Main-Class: LingeredAppForJps Created-By: 15-internal (Oracle Corporation) =================== new one: =================== Manifest-Version: 1.0 Main-Class: LingeredAppForJps Class-Path: file:/D:/ade/jvm/hs_4/build/windows-x64-debug/test-support/ jtreg_open_test_jdk_sun_tools_jps/classes/0/test/lib/ Created-By: 15-internal (Oracle Corporation) =================== --alex > > test/jdk/sun/tools/jps/TestJps.java > ??? No comments. > >> >> The test creates jar with test classes and run it with "java -jar >> ". >> The problem is single "@run Test" tag is executed by JTreg >> inconsistently - sometimes library classes are compiled to test >> directory, sometimes - to library directory. >> The fix explicitly forces required library classes compilation (so >> library files are compiled to library dir) and add classpath >> directories to jar manifest. > > This description doesn't mention jar'ing up additional files so you can see > my confusion (I hope). > > Dan > > >> >> --alex > From alexey.menkov at oracle.com Thu Apr 9 21:17:45 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 9 Apr 2020 14:17:45 -0700 Subject: RFR: JDK-8242282: Test sun/tools/jps/TestJps.java fails after JDK-8237572 In-Reply-To: <41246e47-b358-2ab1-1976-6df8ab32229f@oracle.com> References: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> <7c820d26-e3ae-3ec7-b05d-c7fcaa0b8668@oracle.com> <41246e47-b358-2ab1-1976-6df8ab32229f@oracle.com> Message-ID: <1af14d64-361c-98a0-2d12-12ab2e463541@oracle.com> On 04/09/2020 14:04, Daniel D. Daugherty wrote: > Sorry, pressed "send" too soon. There's no information on how this fix > was tested. Right now we're seeing a varying number of failures in almost > every Tier5 CI job set. Please verify that you've tested Tier5. Tested open/test/jdk/sun/tools/jps/ on all platforms (with --test-repeat 100) I'll schedule tier5 testing, but it takes long time. --alex > > Dan > > > On 4/9/20 5:01 PM, Daniel D. Daugherty wrote: >> On 4/9/20 4:42 PM, Alex Menkov wrote: >>> Hi all, >>> >>> Please review the fix for >>> https://bugs.openjdk.java.net/browse/JDK-8242282 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev/ >> >> test/jdk/sun/tools/jps/LingeredAppForJps.java >> ??? L89: ??????????????? manifestClasspath += " " + new File(path >> ).toURI(); >> ??????? nit - please delete extra space before ')'. >> >> ??? old L91: ????????????? break; >> ??????? So the old version only added the first existing file found in >> the >> ??????? path to the jarArgs. The new version is added all existing files. >> ??????? Maybe I misread the bug report, but I didn't think you wanted to >> ??????? do that. >> >> ??????? Also, can you provide an example of the old manifest file >> versus the >> ??????? new manifest file after this change? >> >> test/jdk/sun/tools/jps/TestJps.java >> ??? No comments. >> >>> >>> The test creates jar with test classes and run it with "java -jar >>> ". >>> The problem is single "@run Test" tag is executed by JTreg >>> inconsistently - sometimes library classes are compiled to test >>> directory, sometimes - to library directory. >>> The fix explicitly forces required library classes compilation (so >>> library files are compiled to library dir) and add classpath >>> directories to jar manifest. >> >> This description doesn't mention jar'ing up additional files so you >> can see >> my confusion (I hope). >> >> Dan >> >> >>> >>> --alex >> > From daniel.daugherty at oracle.com Thu Apr 9 21:22:01 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 9 Apr 2020 17:22:01 -0400 Subject: RFR: JDK-8242282: Test sun/tools/jps/TestJps.java fails after JDK-8237572 In-Reply-To: References: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> <7c820d26-e3ae-3ec7-b05d-c7fcaa0b8668@oracle.com> Message-ID: <79b39148-d9a7-1fac-0474-8985b7674c07@oracle.com> On 4/9/20 5:15 PM, Alex Menkov wrote: > > > On 04/09/2020 14:01, Daniel D. Daugherty wrote: >> On 4/9/20 4:42 PM, Alex Menkov wrote: >>> Hi all, >>> >>> Please review the fix for >>> https://bugs.openjdk.java.net/browse/JDK-8242282 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev/ >> >> test/jdk/sun/tools/jps/LingeredAppForJps.java >> ???? L89: ??????????????? manifestClasspath += " " + new File(path >> ).toURI(); >> ???????? nit - please delete extra space before ')'. > > Done locally. > >> >> ???? old L91: ????????????? break; >> ???????? So the old version only added the first existing file found >> in the >> ???????? path to the jarArgs. The new version is added all existing >> files. >> ???????? Maybe I misread the bug report, but I didn't think you >> wanted to >> ???????? do that. > > The idea of the code is to add to jar only files from test class > directory and don't add files from any other classpath dirs. > With the fix all other classpath dirs are added to manifest "Class-Path". > >> >> ???????? Also, can you provide an example of the old manifest file >> versus the >> ???????? new manifest file after this change? > > in my env > old manifest.mf (generated): > =================== > Main-Class: LingeredAppForJps > =================== > > new one: > =================== > Main-Class: LingeredAppForJps > Class-Path: > file:/D:/ade/jvm/hs_4/build/windows-x64-debug/test-support/jtreg_open_test_jdk_sun_tools_jps/classes/0/test/lib/ > =================== > > old manifest from generated .jar: > > =================== > Manifest-Version: 1.0 > Main-Class: LingeredAppForJps > Created-By: 15-internal (Oracle Corporation) > =================== > > new one: > =================== > Manifest-Version: 1.0 > Main-Class: LingeredAppForJps > Class-Path: file:/D:/ade/jvm/hs_4/build/windows-x64-debug/test-support/ > ?jtreg_open_test_jdk_sun_tools_jps/classes/0/test/lib/ > Created-By: 15-internal (Oracle Corporation) > =================== Looks good. Thumbs up. Dan > > --alex > >> >> test/jdk/sun/tools/jps/TestJps.java >> ???? No comments. >> >>> >>> The test creates jar with test classes and run it with "java -jar >>> ". >>> The problem is single "@run Test" tag is executed by JTreg >>> inconsistently - sometimes library classes are compiled to test >>> directory, sometimes - to library directory. >>> The fix explicitly forces required library classes compilation (so >>> library files are compiled to library dir) and add classpath >>> directories to jar manifest. >> >> This description doesn't mention jar'ing up additional files so you >> can see >> my confusion (I hope). >> >> Dan >> >> >>> >>> --alex >> From daniel.daugherty at oracle.com Thu Apr 9 21:22:47 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 9 Apr 2020 17:22:47 -0400 Subject: RFR: JDK-8242282: Test sun/tools/jps/TestJps.java fails after JDK-8237572 In-Reply-To: <1af14d64-361c-98a0-2d12-12ab2e463541@oracle.com> References: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> <7c820d26-e3ae-3ec7-b05d-c7fcaa0b8668@oracle.com> <41246e47-b358-2ab1-1976-6df8ab32229f@oracle.com> <1af14d64-361c-98a0-2d12-12ab2e463541@oracle.com> Message-ID: On 4/9/20 5:17 PM, Alex Menkov wrote: > > > On 04/09/2020 14:04, Daniel D. Daugherty wrote: >> Sorry, pressed "send" too soon. There's no information on how this fix >> was tested. Right now we're seeing a varying number of failures in >> almost >> every Tier5 CI job set. Please verify that you've tested Tier5. > > Tested open/test/jdk/sun/tools/jps/ on all platforms (with > --test-repeat 100) That'll cover it. > I'll schedule tier5 testing,? but it takes long time. You covered it without running all of tier5. Thanks! Dan > > --alex > >> >> Dan >> >> >> On 4/9/20 5:01 PM, Daniel D. Daugherty wrote: >>> On 4/9/20 4:42 PM, Alex Menkov wrote: >>>> Hi all, >>>> >>>> Please review the fix for >>>> https://bugs.openjdk.java.net/browse/JDK-8242282 >>>> webrev: >>>> http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev/ >>> >>> test/jdk/sun/tools/jps/LingeredAppForJps.java >>> ??? L89: ??????????????? manifestClasspath += " " + new File(path >>> ).toURI(); >>> ??????? nit - please delete extra space before ')'. >>> >>> ??? old L91: ????????????? break; >>> ??????? So the old version only added the first existing file found >>> in the >>> ??????? path to the jarArgs. The new version is added all existing >>> files. >>> ??????? Maybe I misread the bug report, but I didn't think you >>> wanted to >>> ??????? do that. >>> >>> ??????? Also, can you provide an example of the old manifest file >>> versus the >>> ??????? new manifest file after this change? >>> >>> test/jdk/sun/tools/jps/TestJps.java >>> ??? No comments. >>> >>>> >>>> The test creates jar with test classes and run it with "java -jar >>>> ". >>>> The problem is single "@run Test" tag is executed by JTreg >>>> inconsistently - sometimes library classes are compiled to test >>>> directory, sometimes - to library directory. >>>> The fix explicitly forces required library classes compilation (so >>>> library files are compiled to library dir) and add classpath >>>> directories to jar manifest. >>> >>> This description doesn't mention jar'ing up additional files so you >>> can see >>> my confusion (I hope). >>> >>> Dan >>> >>> >>>> >>>> --alex >>> >> From chris.plummer at oracle.com Thu Apr 9 21:28:36 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 9 Apr 2020 14:28:36 -0700 Subject: RFR: JDK-8242282: Test sun/tools/jps/TestJps.java fails after JDK-8237572 In-Reply-To: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> References: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> Message-ID: Hi Alex, The fix looks good, but the test is in need of some commenting. It took a fair amount of staring at the code,? the CR, and the RFR to figure out what it is doing and why. Can you add a few comments? // Add the main class to the jar file. It should only be found in one classpath, therefore only added once. // Keep track of all classpaths other than the one that the main class is in. // Write all additional classpaths to the jar manifest thanks, Chris On 4/9/20 1:42 PM, Alex Menkov wrote: > Hi all, > > Please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8242282 > webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev/ > > The test creates jar with test classes and run it with "java -jar > ". > The problem is single "@run Test" tag is executed by JTreg > inconsistently - sometimes library classes are compiled to test > directory, sometimes - to library directory. > The fix explicitly forces required library classes compilation (so > library files are compiled to library dir) and add classpath > directories to jar manifest. > > --alex From igor.ignatyev at oracle.com Thu Apr 9 21:43:10 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 9 Apr 2020 14:43:10 -0700 Subject: RFR(S) : 8242471 : remove "temporarily" restrictions of nsk/jdi/Argument/value/value004 Message-ID: <9AF57DBE-F26A-45B8-8C03-3034B1FF6F90@oracle.com> http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ > 38 lines changed: 8 ins; 23 del; 7 mod; Hi all, could you please review this small patch for nsk/jdi/Argument/value/value004 test? from JBS: > nsk/jdi/Argument/value/value004 test has restrictions to be run only on solaris-sparc and w/ dt_socket transport, solaris-sparc restriction seems to be not valid any more. the test also should be updated to use skipped exception if there are no suitable connectors available. JBS: https://bugs.openjdk.java.net/browse/JDK-8242471 testing: the changed test on {linux,windows,macosx}-x64 and solaris-sparcv9, w/ the test being skipped on windows-x64 webrev: http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ Thanks, -- Igor From chris.plummer at oracle.com Thu Apr 9 22:15:09 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 9 Apr 2020 15:15:09 -0700 Subject: RFR(S) : 8242471 : remove "temporarily" restrictions of nsk/jdi/Argument/value/value004 In-Reply-To: <9AF57DBE-F26A-45B8-8C03-3034B1FF6F90@oracle.com> References: <9AF57DBE-F26A-45B8-8C03-3034B1FF6F90@oracle.com> Message-ID: Hi Igor, ? 89???????????? log.display("Connector's transport is: " + c.transport().name()); Would be nice if you printed each transport's name (even the skipped ones). That way when reading the log after getting SkippedException you can see which transports were attempted. You removed the following: ? 50? * ================================================ ? 51? * WARNING: ? 52? *???????? Temporarily the test is prepared only for ? 53? *???????? Sparc.Solaris.dt_socket-transport of RawCommandLineLaunch ? 54? *???????? connector ? 55? * ================================================ Isn't this still somewhat true? It's still requires dt_socket, but no longer solaris-sparc. This is part of the reason I asked above to print which transports are attempted. I'm curious what the skipped transport is on Windows. thanks, Chris On 4/9/20 2:43 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ >> 38 lines changed: 8 ins; 23 del; 7 mod; > Hi all, > > could you please review this small patch for nsk/jdi/Argument/value/value004 test? > from JBS: >> nsk/jdi/Argument/value/value004 test has restrictions to be run only on solaris-sparc and w/ dt_socket transport, solaris-sparc restriction seems to be not valid any more. the test also should be updated to use skipped exception if there are no suitable connectors available. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242471 > testing: the changed test on {linux,windows,macosx}-x64 and solaris-sparcv9, w/ the test being skipped on windows-x64 > webrev: http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ > > Thanks, > -- Igor From alexey.menkov at oracle.com Thu Apr 9 22:50:39 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 9 Apr 2020 15:50:39 -0700 Subject: RFR: JDK-8242282: Test sun/tools/jps/TestJps.java fails after JDK-8237572 In-Reply-To: References: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> Message-ID: <14d1ed7c-6b5c-6aa2-a637-df2b1320abeb@oracle.com> Hi Chris, I tried to describe main idea of the code. updated webrev: http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev.01/ the only change vs prev. webrev is added comment in LingeredAppForJps.java --alex On 04/09/2020 14:28, Chris Plummer wrote: > Hi Alex, > > The fix looks good, but the test is in need of some commenting. It took > a fair amount of staring at the code,? the CR, and the RFR to figure out > what it is doing and why. Can you add a few comments? > > // Add the main class to the jar file. It should only be found in one > classpath, therefore only added once. > > // Keep track of all classpaths other than the one that the main class > is in. > > // Write all additional classpaths to the jar manifest > > thanks, > > Chris > > On 4/9/20 1:42 PM, Alex Menkov wrote: >> Hi all, >> >> Please review the fix for >> https://bugs.openjdk.java.net/browse/JDK-8242282 >> webrev: >> http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev/ >> >> The test creates jar with test classes and run it with "java -jar >> ". >> The problem is single "@run Test" tag is executed by JTreg >> inconsistently - sometimes library classes are compiled to test >> directory, sometimes - to library directory. >> The fix explicitly forces required library classes compilation (so >> library files are compiled to library dir) and add classpath >> directories to jar manifest. >> >> --alex > > From chris.plummer at oracle.com Thu Apr 9 22:55:36 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 9 Apr 2020 15:55:36 -0700 Subject: RFR(XS) 8237250: pmap and pstack should do a better of making it clear that they are not supported on Mac OS X Message-ID: <99bca2cd-61ac-e1c7-17a0-f357edf03d65@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8237250 http://cr.openjdk.java.net/~cjplummer/8237250/webrev.01/index.html Details are in the CR. thanks, Chris From chris.plummer at oracle.com Thu Apr 9 22:58:48 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 9 Apr 2020 15:58:48 -0700 Subject: RFR: JDK-8242282: Test sun/tools/jps/TestJps.java fails after JDK-8237572 In-Reply-To: <14d1ed7c-6b5c-6aa2-a637-df2b1320abeb@oracle.com> References: <3393f299-59c3-1b00-749e-352f74414341@oracle.com> <14d1ed7c-6b5c-6aa2-a637-df2b1320abeb@oracle.com> Message-ID: <26551906-309a-d8fc-054f-a2eddf1be673@oracle.com> Hi Alex, Please add a newline between lines 70 and 71. ? 77???????? // are writen the jar manifest. "writen" -> "written to" No need to see another review. thanks, Chris On 4/9/20 3:50 PM, Alex Menkov wrote: > Hi Chris, > > I tried to describe main idea of the code. > > updated webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev.01/ > > the only change vs prev. webrev is added comment in > LingeredAppForJps.java > > --alex > > On 04/09/2020 14:28, Chris Plummer wrote: >> Hi Alex, >> >> The fix looks good, but the test is in need of some commenting. It >> took a fair amount of staring at the code,? the CR, and the RFR to >> figure out what it is doing and why. Can you add a few comments? >> >> // Add the main class to the jar file. It should only be found in one >> classpath, therefore only added once. >> >> // Keep track of all classpaths other than the one that the main >> class is in. >> >> // Write all additional classpaths to the jar manifest >> >> thanks, >> >> Chris >> >> On 4/9/20 1:42 PM, Alex Menkov wrote: >>> Hi all, >>> >>> Please review the fix for >>> https://bugs.openjdk.java.net/browse/JDK-8242282 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/jdk15/jpsTest_ClsNotFound/webrev/ >>> >>> The test creates jar with test classes and run it with "java -jar >>> ". >>> The problem is single "@run Test" tag is executed by JTreg >>> inconsistently - sometimes library classes are compiled to test >>> directory, sometimes - to library directory. >>> The fix explicitly forces required library classes compilation (so >>> library files are compiled to library dir) and add classpath >>> directories to jar manifest. >>> >>> --alex >> >> From igor.ignatyev at oracle.com Thu Apr 9 23:13:11 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 9 Apr 2020 16:13:11 -0700 Subject: RFR(S) : 8242471 : remove "temporarily" restrictions of nsk/jdi/Argument/value/value004 In-Reply-To: References: <9AF57DBE-F26A-45B8-8C03-3034B1FF6F90@oracle.com> Message-ID: <2E0BCF33-C044-4D84-B254-354AE8C03F48@oracle.com> Hi Chris, I looked what transport got skipped on Windows, and it's dt_shmem, as I didn't see any reasons why this test should not be run w/ this transport, I looked deeper and I found the place which needs to be updated to make the test work w/ dt_shmem. so now the test doesn't skip any transports (and thus the removed warning isn't even partially true) and only skips connector other than c.s.j.RawCommandLineLaunch, to make it cleaner the test now logs the skipped connectors, e.g. on my mac, I'm getting the following in .jtr > skipping com.sun.jdi.CommandLineLaunch (defaults: home=/Users/iignatye/ws/jdk/jdk/build/macosx-x64/images/jdk, options=, main=, suspend=true, quote=", vmexec=java) I've retested the patch on the same platforms as before and now it passes on windows as well. incremental webrev: http://cr.openjdk.java.net/~iignatyev//8242471/webrev.0-1/index.html full webrev: http://cr.openjdk.java.net/~iignatyev//8242471/webrev.01/index.html Thanks, -- Igor > On Apr 9, 2020, at 3:15 PM, Chris Plummer wrote: > > Hi Igor, > > 89 log.display("Connector's transport is: " + c.transport().name()); > > Would be nice if you printed each transport's name (even the skipped ones). That way when reading the log after getting SkippedException you can see which transports were attempted. > > You removed the following: > > 50 * ================================================ > 51 * WARNING: > 52 * Temporarily the test is prepared only for > 53 * Sparc.Solaris.dt_socket-transport of RawCommandLineLaunch > 54 * connector > 55 * ================================================ > > Isn't this still somewhat true? It's still requires dt_socket, but no longer solaris-sparc. This is part of the reason I asked above to print which transports are attempted. I'm curious what the skipped transport is on Windows. > > thanks, > > Chris > > On 4/9/20 2:43 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ >>> 38 lines changed: 8 ins; 23 del; 7 mod; >> Hi all, >> >> could you please review this small patch for nsk/jdi/Argument/value/value004 test? >> from JBS: >>> nsk/jdi/Argument/value/value004 test has restrictions to be run only on solaris-sparc and w/ dt_socket transport, solaris-sparc restriction seems to be not valid any more. the test also should be updated to use skipped exception if there are no suitable connectors available. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8242471 >> testing: the changed test on {linux,windows,macosx}-x64 and solaris-sparcv9, w/ the test being skipped on windows-x64 >> webrev: http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ >> >> Thanks, >> -- Igor > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiefu at tencent.com Fri Apr 10 01:49:02 2020 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Fri, 10 Apr 2020 01:49:02 +0000 Subject: RFR: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker Message-ID: <1408ACE5-DA99-4687-94A8-5C659287BC3C@tencent.com> Hi all, JBS: https://bugs.openjdk.java.net/browse/JDK-8242480 Webrev: http://cr.openjdk.java.net/~jiefu/8242480/webrev.00/ Negative values were returned by getFreeSwapSpaceSize() in our docker testing. The reason is that current implementation doesn't consider the situation when memory.limit_in_bytes == memory.memsw.limit_in_bytes, which means do not use the swap space at all. In src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java, let's see ------------------------------------------------ 71 public long getFreeSwapSpaceSize() { 72 if (containerMetrics != null) { 73 long memSwapLimit = containerMetrics.getMemoryAndSwapLimit(); 74 long memLimit = containerMetrics.getMemoryLimit(); 75 if (memSwapLimit >= 0 && memLimit >= 0) { 76 for (int attempt = 0; attempt < MAX_ATTEMPTS_NUMBER; attempt++) { 77 long memSwapUsage = containerMetrics.getMemoryAndSwapUsage(); 78 long memUsage = containerMetrics.getMemoryUsage(); 79 if (memSwapUsage > 0 && memUsage > 0) { 80 // We read "memory usage" and "memory and swap usage" not atomically, 81 // and it's possible to get the negative value when subtracting these two. 82 // If this happens just retry the loop for a few iterations. 83 if ((memSwapUsage - memUsage) >= 0) { 84 return memSwapLimit - memLimit - (memSwapUsage - memUsage); 85 } 86 } 87 } 88 } 89 } 90 return getFreeSwapSpaceSize0(); 91 } ------------------------------------------------ If memSwapLimit (@line 73) equals memLimit (@line 74), then getFreeSwapSpaceSize() may return a negative value @line 84. It would be better to fix it. Could you please review it and give me some advice? Thanks a lot. Best regards, Jie -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Apr 10 03:35:17 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 9 Apr 2020 20:35:17 -0700 Subject: RFR(S) : 8242471 : remove "temporarily" restrictions of nsk/jdi/Argument/value/value004 In-Reply-To: <2E0BCF33-C044-4D84-B254-354AE8C03F48@oracle.com> References: <9AF57DBE-F26A-45B8-8C03-3034B1FF6F90@oracle.com> <2E0BCF33-C044-4D84-B254-354AE8C03F48@oracle.com> Message-ID: <0aaca1c1-34c1-dd3b-92bb-d86c82860a81@oracle.com> An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Fri Apr 10 03:49:54 2020 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Thu, 9 Apr 2020 20:49:54 -0700 Subject: RFR(S) : 8242471 : remove "temporarily" restrictions of nsk/jdi/Argument/value/value004 In-Reply-To: <0aaca1c1-34c1-dd3b-92bb-d86c82860a81@oracle.com> References: <0aaca1c1-34c1-dd3b-92bb-d86c82860a81@oracle.com> Message-ID: <6E9E8D43-1FDF-4E14-AAAD-BBA2FA3BCA7A@oracle.com> Thanks Chris! Would you consider this trivial or should I wait for another review? ? Igor > On Apr 9, 2020, at 8:35 PM, Chris Plummer wrote: > > ? > Hi Igor, > > The changes looks good. > > thanks, > > Chris > >> On 4/9/20 4:13 PM, Igor Ignatyev wrote: >> Hi Chris, >> >> I looked what transport got skipped on Windows, and it's dt_shmem, as I didn't see any reasons why this test should not be run w/ this transport, I looked deeper and I found the place which needs to be updated to make the test work w/ dt_shmem. so now the test doesn't skip any transports (and thus the removed warning isn't even partially true) and only skips connector other than c.s.j.RawCommandLineLaunch, to make it cleaner the test now logs the skipped connectors, e.g. on my mac, I'm getting the following in .jtr >>> skipping com.sun.jdi.CommandLineLaunch (defaults: home=/Users/iignatye/ws/jdk/jdk/build/macosx-x64/images/jdk, options=, main=, suspend=true, quote=", vmexec=java) >> >> >> I've retested the patch on the same platforms as before and now it passes on windows as well. >> >> incremental webrev: http://cr.openjdk.java.net/~iignatyev//8242471/webrev.0-1/index.html >> full webrev: http://cr.openjdk.java.net/~iignatyev//8242471/webrev.01/index.html >> >> Thanks, >> -- Igor >> >>> On Apr 9, 2020, at 3:15 PM, Chris Plummer wrote: >>> >>> Hi Igor, >>> >>> 89 log.display("Connector's transport is: " + c.transport().name()); >>> >>> Would be nice if you printed each transport's name (even the skipped ones). That way when reading the log after getting SkippedException you can see which transports were attempted. >>> >>> You removed the following: >>> >>> 50 * ================================================ >>> 51 * WARNING: >>> 52 * Temporarily the test is prepared only for >>> 53 * Sparc.Solaris.dt_socket-transport of RawCommandLineLaunch >>> 54 * connector >>> 55 * ================================================ >>> >>> Isn't this still somewhat true? It's still requires dt_socket, but no longer solaris-sparc. This is part of the reason I asked above to print which transports are attempted. I'm curious what the skipped transport is on Windows. >>> >>> thanks, >>> >>> Chris >>> >>>> On 4/9/20 2:43 PM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ >>>>> 38 lines changed: 8 ins; 23 del; 7 mod; >>>> Hi all, >>>> >>>> could you please review this small patch for nsk/jdi/Argument/value/value004 test? >>>> from JBS: >>>>> nsk/jdi/Argument/value/value004 test has restrictions to be run only on solaris-sparc and w/ dt_socket transport, solaris-sparc restriction seems to be not valid any more. the test also should be updated to use skipped exception if there are no suitable connectors available. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242471 >>>> testing: the changed test on {linux,windows,macosx}-x64 and solaris-sparcv9, w/ the test being skipped on windows-x64 >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ >>>> >>>> Thanks, >>>> -- Igor >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Apr 10 04:44:58 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 9 Apr 2020 21:44:58 -0700 Subject: RFR(S) 8235220: ClhsdbScanOops.java fails with sun.jvm.hotspot.types.WrongTypeException Message-ID: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8235220 http://cr.openjdk.java.net/~cjplummer/8235220/webrev.00 First off, thanks to Ioi for tracking this one down and proposing the fix. The test is executing the clhsdb "scanoops" command, which scans the specified heap address range looking for objects of the specified type (or all objects if no type is specified). The test determines the address range by first using clhsdb "universe" to get the start and end of the eden space. scanoops then iterates over this entire range, calling RobustOopDeterminator.oopLooksValid() on each oop as it iterates over the range. The problem is eventually you'll end up past the initialized part of the heap. That causes VirtualBaseConstructor.findDynamicTypeForAddress() to return null, resulting in throwing a WrongTypeException. RobustOopDeterminator.oopLooksValid() should catch this exception and return false when it happens. The CR mentions a few different failure modes. This only fixes the WrongTypeException failure. The NullPointerException is only on OSX and I believe is the same as JDK-8241158 [1], which happens when dumping the heap, so it seems probable that it is also turning up when scanning part of the heap. I think this bug was preventing us from ever seeing the WrongTypeException on OSX. Then there also JDK-8230731 [2] on Windows, which seems to prevent ever seeing the WrongTypeException on Windows. [1] https://bugs.openjdk.java.net/browse/JDK-8241158 [2] https://bugs.openjdk.java.net/browse/JDK-8230731 thanks, Chris From chris.plummer at oracle.com Fri Apr 10 04:45:29 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 9 Apr 2020 21:45:29 -0700 Subject: RFR(S) : 8242471 : remove "temporarily" restrictions of nsk/jdi/Argument/value/value004 In-Reply-To: <6E9E8D43-1FDF-4E14-AAAD-BBA2FA3BCA7A@oracle.com> References: <0aaca1c1-34c1-dd3b-92bb-d86c82860a81@oracle.com> <6E9E8D43-1FDF-4E14-AAAD-BBA2FA3BCA7A@oracle.com> Message-ID: <72d4adef-57bf-0473-933e-398b7224e6a4@oracle.com> An HTML attachment was scrubbed... URL: From suenaga at oss.nttdata.com Fri Apr 10 04:46:28 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 10 Apr 2020 13:46:28 +0900 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes Message-ID: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/ We've discussed to use Thread-Local Handshake in some JVMTI functions [1]. This change is for monitor functions. It affects GetOwnedMonitorInfo(), GetOwnedMonitorStackDepthInfo(), GetCurrentContendedMonitor(). It passed tests on submit repo (mach5-one-ysuenaga-JDK-8242425-20200410-0228-10075639), and also I confirmed to pass following tests: - serviceability/jvmti/GetOwnedMonitorInfo - serviceability/jvmti/GetOwnedMonitorStackDepthInfo - vmTestbase/nsk/jvmti/GetCurrentContendedMonitor - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo Thanks, Yasumasa [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html From ioi.lam at oracle.com Fri Apr 10 05:21:06 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 9 Apr 2020 22:21:06 -0700 Subject: RFR(S) 8235220: ClhsdbScanOops.java fails with sun.jvm.hotspot.types.WrongTypeException In-Reply-To: References: Message-ID: <27d01f05-c5e9-a976-910e-eddeab6ab547@oracle.com> Hi Chris, Thanks for fixing this. It looks good to me. - Ioi On 4/9/20 9:44 PM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8235220 > http://cr.openjdk.java.net/~cjplummer/8235220/webrev.00 > > First off, thanks to Ioi for tracking this one down and proposing the > fix. > > The test is executing the clhsdb "scanoops" command, which scans the > specified heap address range looking for objects of the specified type > (or all objects if no type is specified). The test determines the > address range by first using clhsdb "universe" to get the start and > end of the eden space. scanoops then iterates over this entire range, > calling RobustOopDeterminator.oopLooksValid() on each oop as it > iterates over the range. The problem is eventually you'll end up past > the initialized part of the heap. That causes > VirtualBaseConstructor.findDynamicTypeForAddress() to return null, > resulting in throwing a WrongTypeException. > RobustOopDeterminator.oopLooksValid() should catch this exception and > return false when it happens. > > The CR mentions a few different failure modes. This only fixes the > WrongTypeException failure. The NullPointerException is only on OSX > and I believe is the same as JDK-8241158 [1], which happens when > dumping the heap, so it seems probable that it is also turning up when > scanning part of the heap. I think this bug was preventing us from > ever seeing the WrongTypeException on OSX. Then there also JDK-8230731 > [2] on Windows, which seems to prevent ever seeing the > WrongTypeException on Windows. > > [1] https://bugs.openjdk.java.net/browse/JDK-8241158 > [2] https://bugs.openjdk.java.net/browse/JDK-8230731 > > thanks, > > Chris From serguei.spitsyn at oracle.com Fri Apr 10 05:50:33 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 Apr 2020 22:50:33 -0700 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> Message-ID: <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> An HTML attachment was scrubbed... URL: From suenaga at oss.nttdata.com Fri Apr 10 08:05:34 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 10 Apr 2020 17:05:34 +0900 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> Message-ID: <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> Hi Serguei, Thanks for your comment! I uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/ I ran following tests, and all of them were passed on my Linux x64. - vmTestbase/nsk/jvmti/GetCurrentContendedMonitor - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo - vmTestbase/nsk/jdi - vmTestbase/nsk/jdwp - serviceability/jvmti/GetOwnedMonitorInfo - serviceability/jvmti/GetOwnedMonitorStackDepthInfo - serviceability/jdwp Thanks, Yasumasa On 2020/04/10 14:50, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > It looks pretty good in general. > A couple of comments though. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html > > 650 JvmtiEnvBase::get_current_contended_monitor(JavaThread *java_thread, jobject *monitor_ptr) { > 651 assert(!Thread::current()->is_VM_thread() && > 652 (Thread::current() == java_thread || > 653 Thread::current() == java_thread->active_handshaker()), > 654 "call by myself or at direct handshake"); > > ... > > 685 JvmtiEnvBase::get_owned_monitors(JavaThread* java_thread, > 686 GrowableArray *owned_monitors_list) { > 687 jvmtiError err = JVMTI_ERROR_NONE; > 688 assert(!Thread::current()->is_VM_thread() && > 689 (Thread::current() == java_thread || > 690 Thread::current() == java_thread->active_handshaker()), > 691 "call by myself or at direct handshake"); > > I'd suggest to add this at the beginning: > ? JavaThread *current_jt = JavaThread::current(); > > > 676 JavaThread *current_jt = reinterpret_cast(JavaThread::current()); > > There is not need in reinterpret_cast. Also, you can use the current_jt defined above. > > Also, please, removed these two definitions as they became unused with your fix: > ?? src/hotspot/share/runtime/vmOperations.hpp: template(GGetCurrentContendedMonitoretOwnedMonitorInfo) \ > ?? src/hotspot/share/runtime/vmOperations.hpp: template()??????????? \ > > The impacted JVMTI monitor functions are used in the JDWP agent to support the JDI ThreadReference implementation. > To be safe the JDI & JDWP tests have to be run as well. It is well covered by the tier-5. > > Thanks, > Serguei > > > On 4/9/20 21:46, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/ >> >> We've discussed to use Thread-Local Handshake in some JVMTI functions [1]. >> This change is for monitor functions. It affects GetOwnedMonitorInfo(), GetOwnedMonitorStackDepthInfo(), GetCurrentContendedMonitor(). >> >> It passed tests on submit repo (mach5-one-ysuenaga-JDK-8242425-20200410-0228-10075639), and also I confirmed to pass following tests: >> >> ?- serviceability/jvmti/GetOwnedMonitorInfo >> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html > From serguei.spitsyn at oracle.com Fri Apr 10 08:21:49 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 10 Apr 2020 01:21:49 -0700 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> Message-ID: An HTML attachment was scrubbed... URL: From suenaga at oss.nttdata.com Fri Apr 10 11:30:09 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 10 Apr 2020 20:30:09 +0900 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> Message-ID: Hi Serguei, I use current_jt in this webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ I tested this change with vmTestbase/nsk/jvmti, they are fine on my Linux x64. Thanks, Yasumasa On 2020/04/10 17:21, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > Thank you for the update. > > Minor: > http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/src/hotspot/share/prims/jvmtiEnvBase.cpp.udiff.html > > + err = get_locked_objects_in_frame(JavaThread::current(), java_thread, jvf, owned_monitors_list, depth-1); . . . > > + JvmtiMonitorClosure jmc(java_thread, JavaThread::current(), owned_monitors_list, this); > > You can use current_jt instead of JavaThread::current() above. > > There is also some test coverage in the vmTestbase/nsk/jvmti/scenarios tests. > This one as well: > test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest > Probably it is easier to run all vmTestbase/nsk/jvmti tests. > > Thanks, > Serguei > > > On 4/10/20 01:05, Yasumasa Suenaga wrote: >> Hi Serguei, >> >> Thanks for your comment! >> I uploaded new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/ >> >> I ran following tests, and all of them were passed on my Linux x64. >> >> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >> ?- vmTestbase/nsk/jdi >> ?- vmTestbase/nsk/jdwp >> ?- serviceability/jvmti/GetOwnedMonitorInfo >> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >> ?- serviceability/jdwp >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/10 14:50, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> It looks pretty good in general. >>> A couple of comments though. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html >>> >>> 650 JvmtiEnvBase::get_current_contended_monitor(JavaThread *java_thread, jobject *monitor_ptr) { >>> 651 assert(!Thread::current()->is_VM_thread() && >>> 652 (Thread::current() == java_thread || >>> 653 Thread::current() == java_thread->active_handshaker()), >>> 654 "call by myself or at direct handshake"); >>> >>> ? ... >>> >>> 685 JvmtiEnvBase::get_owned_monitors(JavaThread* java_thread, >>> ? 686 GrowableArray *owned_monitors_list) { >>> ? 687?? jvmtiError err = JVMTI_ERROR_NONE; >>> 688 assert(!Thread::current()->is_VM_thread() && >>> 689 (Thread::current() == java_thread || >>> 690 Thread::current() == java_thread->active_handshaker()), >>> 691 "call by myself or at direct handshake"); >>> >>> I'd suggest to add this at the beginning: >>> ?? JavaThread *current_jt = JavaThread::current(); >>> >>> >>> 676 JavaThread *current_jt = reinterpret_cast(JavaThread::current()); >>> >>> There is not need in reinterpret_cast. Also, you can use the current_jt defined above. >>> >>> Also, please, removed these two definitions as they became unused with your fix: >>> ??? src/hotspot/share/runtime/vmOperations.hpp: template(GGetCurrentContendedMonitoretOwnedMonitorInfo) \ >>> ??? src/hotspot/share/runtime/vmOperations.hpp: template()??????????? \ >>> >>> The impacted JVMTI monitor functions are used in the JDWP agent to support the JDI ThreadReference implementation. >>> To be safe the JDI & JDWP tests have to be run as well. It is well covered by the tier-5. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/9/20 21:46, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this change: >>>> >>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/ >>>> >>>> We've discussed to use Thread-Local Handshake in some JVMTI functions [1]. >>>> This change is for monitor functions. It affects GetOwnedMonitorInfo(), GetOwnedMonitorStackDepthInfo(), GetCurrentContendedMonitor(). >>>> >>>> It passed tests on submit repo (mach5-one-ysuenaga-JDK-8242425-20200410-0228-10075639), and also I confirmed to pass following tests: >>>> >>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html >>> > From mandy.chung at oracle.com Sun Apr 12 03:13:07 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 11 Apr 2020 20:13:07 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> Message-ID: Please review the delta patch: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/ Incremental specdiff: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html This is to follow a discussion [1] on Class::descriptorString and MethodType::descriptorString for hidden classes.?? The proposal is to define the descriptor string for a hidden class of this form: ??? "L" + N + ";" + "/" + The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and `MethodType::descriptorString` are updated to return the descriptor of this form for a hidden class.?? To support hidden class, `java.lang.invoke.TypeDescriptor` spec is revised such that a `TypeDescriptor` object can represent an entity that may not be described in nominal form. ??? This change affects JVM TI, JDWP and JDI.??? The spec change includes a couple other JVM TI and java.instrument spec clarification w.r.t. hidden classes that Serguei has been working on. Mandy [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html ---------------- As a record, the above patch is applied on the top: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06/ webrev.06 includes the following changes that have been reviewed: 1. rename "weak hidden" and Klass::is_hidden_weak to is_non_strong_hidden 2. remove unused `setImplMethod` method from lambda proxy class 3. include Serguei's patch to fix JDK-8242166: regression in JDI ClassUnload events 4. drop the uniqueness guarantee of the suffix of the hidden class's name On 3/31/20 8:01 PM, Mandy Chung wrote: > Thanks to the review feedbacks. > > Updated webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ > > Delta between webrev.03 and webrev.04: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ > > > Summary of changes is: > 1. Update javac to retain the previous behavior when compiling to > target release <= 14 where lambda proxy class is not a nestmate > 2. Rename Class::isHiddenClass to Class::isHidden > 3. Address Joe's feedback on the CSR to document the behavior of the > relevant methods in java.lang.Class for hidden classes > 4. Add test case for unloadable class with nest host error > 5. Add test cases for hidden classes with different kinds of class or > interface > 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class" > 7. Small changes in response to Remi, Coleen, Paul's review comments > 8. Fix copyright headers > 9. Fix @modules in tests > > Most of the changes above have also been reviewed as separate patches. > > Thanks > Mandy > > On 3/26/20 4:57 PM, Mandy Chung wrote: >> Please review the implementation of JEP 371: Hidden Classes. The main >> changes are in core-libs and hotspot runtime area.? Small changes are >> made in javac, VM compiler (intrinsification of >> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been reviewed >> and is in the finalized state (see specdiff and javadoc below for >> reference). >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >> >> >> javadoc/specdiff >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >> >> >> JVMS 5.4.4 change: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >> >> >> CSR: >> https://bugs.openjdk.java.net/browse/JDK-8238359 >> >> Thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Mon Apr 13 14:34:01 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 13 Apr 2020 10:34:01 -0400 Subject: RFR (S) 8074292: nsk/jdb/kill/kill001: generateOopMap.cpp assert(bb->is_reachable()) failed Message-ID: Summary: Do not install async exceptions at_safepoint for each bytecode. See CR for a lot more details.? This change calls a new InterpreterRuntime::at_safepoint_async_safe() which installs the async exception in the interpreter at backward branches and returns.? This uses safepoint polling code in the interpreter for each platform.? These changes (cross) compile on platforms that Oracle doesn't support but I don't know if they work. I'm not convinced the platform specific changes are necessary, because calls to the runtime from many bytecodes will install the async exception, so it's essentially installed "enough" for this deprecated feature.? I tested the changes with *and* without the platform specific changes with no failure, which included the jdb, jdi and jvmti serviceability tests. This change also makes InterpreterRuntime::monitorexit a JRT_LEAF bytecode. The code to check for exceptions is outside the runtime call.? I ran the JCK vm and lang tests on this change with no failure. Tested with tier1-6. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8074292.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8074292 Thanks, Coleen From igor.ignatyev at oracle.com Mon Apr 13 17:35:42 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 13 Apr 2020 10:35:42 -0700 Subject: RFR(S) : 8242471 : remove "temporarily" restrictions of nsk/jdi/Argument/value/value004 In-Reply-To: <72d4adef-57bf-0473-933e-398b7224e6a4@oracle.com> References: <0aaca1c1-34c1-dd3b-92bb-d86c82860a81@oracle.com> <6E9E8D43-1FDF-4E14-AAAD-BBA2FA3BCA7A@oracle.com> <72d4adef-57bf-0473-933e-398b7224e6a4@oracle.com> Message-ID: sure. @alias, can I get a 2nd review for this patch? Thanks, -- Igor > On Apr 9, 2020, at 9:45 PM, Chris Plummer wrote: > > Hi Igor, > > I think it's best to get another review. > > thanks, > > Chris > > On 4/9/20 8:49 PM, Igor Ignatev wrote: >> Thanks Chris! Would you consider this trivial or should I wait for another review? >> >> ? Igor >> >>> On Apr 9, 2020, at 8:35 PM, Chris Plummer wrote: >>> >>> ? >>> Hi Igor, >>> >>> The changes looks good. >>> >>> thanks, >>> >>> Chris >>> >>> On 4/9/20 4:13 PM, Igor Ignatyev wrote: >>>> Hi Chris, >>>> >>>> I looked what transport got skipped on Windows, and it's dt_shmem, as I didn't see any reasons why this test should not be run w/ this transport, I looked deeper and I found the place which needs to be updated to make the test work w/ dt_shmem. so now the test doesn't skip any transports (and thus the removed warning isn't even partially true) and only skips connector other than c.s.j.RawCommandLineLaunch, to make it cleaner the test now logs the skipped connectors, e.g. on my mac, I'm getting the following in .jtr >>>>> skipping com.sun.jdi.CommandLineLaunch (defaults: home=/Users/iignatye/ws/jdk/jdk/build/macosx-x64/images/jdk, options=, main=, suspend=true, quote=", vmexec=java) >>>> >>>> >>>> I've retested the patch on the same platforms as before and now it passes on windows as well. >>>> >>>> incremental webrev: http://cr.openjdk.java.net/~iignatyev//8242471/webrev.0-1/index.html >>>> full webrev: http://cr.openjdk.java.net/~iignatyev//8242471/webrev.01/index.html >>>> >>>> Thanks, >>>> -- Igor >>>> >>>>> On Apr 9, 2020, at 3:15 PM, Chris Plummer > wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> 89 log.display("Connector's transport is: " + c.transport().name()); >>>>> >>>>> Would be nice if you printed each transport's name (even the skipped ones). That way when reading the log after getting SkippedException you can see which transports were attempted. >>>>> >>>>> You removed the following: >>>>> >>>>> 50 * ================================================ >>>>> 51 * WARNING: >>>>> 52 * Temporarily the test is prepared only for >>>>> 53 * Sparc.Solaris.dt_socket-transport of RawCommandLineLaunch >>>>> 54 * connector >>>>> 55 * ================================================ >>>>> >>>>> Isn't this still somewhat true? It's still requires dt_socket, but no longer solaris-sparc. This is part of the reason I asked above to print which transports are attempted. I'm curious what the skipped transport is on Windows. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 4/9/20 2:43 PM, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ >>>>>>> 38 lines changed: 8 ins; 23 del; 7 mod; >>>>>> Hi all, >>>>>> >>>>>> could you please review this small patch for nsk/jdi/Argument/value/value004 test? >>>>>> from JBS: >>>>>>> nsk/jdi/Argument/value/value004 test has restrictions to be run only on solaris-sparc and w/ dt_socket transport, solaris-sparc restriction seems to be not valid any more. the test also should be updated to use skipped exception if there are no suitable connectors available. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242471 >>>>>> testing: the changed test on {linux,windows,macosx}-x64 and solaris-sparcv9, w/ the test being skipped on windows-x64 >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> -- Igor >>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Mon Apr 13 17:36:08 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 13 Apr 2020 10:36:08 -0700 Subject: RFR(S/T) : 8242313 : use reproducible random in hotspot svc tests In-Reply-To: <963A7599-45FD-421A-AB68-09188F290791@oracle.com> References: <963A7599-45FD-421A-AB68-09188F290791@oracle.com> Message-ID: <9D4159AF-7248-4A5F-824E-3ABC26CBD970@oracle.com> ping? -- Igor > On Apr 8, 2020, at 10:21 AM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8242313/webrev.00 >> 16 lines changed: 10 ins; 0 del; 6 mod; > > Hi all, > > could you please review the patch which updates hotspot/jtreg/serviceability tests in the same way as 8242310[1,2] updates compiler tests: >> marks ... tests w/ randomness k/w and uses Utils.getRandomInstance() instead of Random w/ _random_ seeds where possible? To identify tests which should be marked, I've used both static (in a form of analyzing classes which directly or indirectly depend on Random/SecureRandom/ThreadLocalRandom) and dynamic (by instrumenting the said classes to log tests which called their 'next' methods) analyses. I've decided *not* to mark tests which use SecureRandom only via File.createTemp* b/c in all such cases temp files are not used as a source of randomness, but rather just a reliable way to get a new/empty file/dir. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242313 > webrev: http://cr.openjdk.java.net/~iignatyev/8242313/webrev.00 > NB the patch depends on 8241707[3], which is currently under review[4]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8242310 > [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037828.html > [3] https://bugs.openjdk.java.net/browse/JDK-8241707 > [4] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041300.html > > Thanks, > -- Igor From alexey.menkov at oracle.com Mon Apr 13 18:30:07 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 13 Apr 2020 11:30:07 -0700 Subject: RFR(S) : 8242471 : remove "temporarily" restrictions of nsk/jdi/Argument/value/value004 In-Reply-To: References: <0aaca1c1-34c1-dd3b-92bb-d86c82860a81@oracle.com> <6E9E8D43-1FDF-4E14-AAAD-BBA2FA3BCA7A@oracle.com> <72d4adef-57bf-0473-933e-398b7224e6a4@oracle.com> Message-ID: LGTM --alex On 04/13/2020 10:35, Igor Ignatyev wrote: > sure. > > @alias, can I get a 2nd review for this patch? > > Thanks, > -- Igor > >> On Apr 9, 2020, at 9:45 PM, Chris Plummer > > wrote: >> >> Hi Igor, >> >> I think it's best to get another review. >> >> thanks, >> >> Chris >> >> On 4/9/20 8:49 PM, Igor Ignatev wrote: >>> Thanks Chris! Would you consider this trivial or should I wait for >>> another review? >>> >>> ? Igor >>> >>>> On Apr 9, 2020, at 8:35 PM, Chris Plummer >>>> wrote: >>>> >>>> ? >>>> Hi Igor, >>>> >>>> The changes looks good. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 4/9/20 4:13 PM, Igor Ignatyev wrote: >>>>> Hi Chris, >>>>> >>>>> I looked what transport got skipped on Windows, and it's dt_shmem, >>>>> as I didn't see any reasons why this test should not be run w/ this >>>>> transport, I looked deeper and I found the place which needs to be >>>>> updated to make the test work w/ dt_shmem. so now the test doesn't >>>>> skip any transports (and thus the removed warning isn't even >>>>> partially true) and only skips connector other than >>>>> c.s.j.RawCommandLineLaunch, to make it cleaner the test now logs >>>>> the skipped connectors, e.g. on my mac, I'm getting the following >>>>> in .jtr >>>>>> skipping com.sun.jdi.CommandLineLaunch (defaults: >>>>>> home=/Users/iignatye/ws/jdk/jdk/build/macosx-x64/images/jdk, >>>>>> options=, main=, suspend=true, quote=", vmexec=java) >>>>> >>>>> I've retested the patch on the same platforms as before and now it >>>>> passes on windows as well. >>>>> >>>>> incremental webrev: >>>>> http://cr.openjdk.java.net/~iignatyev//8242471/webrev.0-1/index.html >>>>> full webrev: >>>>> http://cr.openjdk.java.net/~iignatyev//8242471/webrev.01/index.html >>>>> >>>>> Thanks, >>>>> -- Igor >>>>> >>>>>> On Apr 9, 2020, at 3:15 PM, Chris Plummer >>>>>> > wrote: >>>>>> >>>>>> Hi Igor, >>>>>> >>>>>> ? 89???????????? log.display("Connector's transport is: " + >>>>>> c.transport().name()); >>>>>> >>>>>> Would be nice if you printed each transport's name (even the >>>>>> skipped ones). That way when reading the log after getting >>>>>> SkippedException you can see which transports were attempted. >>>>>> >>>>>> You removed the following: >>>>>> >>>>>> ? 50? * ================================================ >>>>>> ? 51? * WARNING: >>>>>> ? 52? *???????? Temporarily the test is prepared only for >>>>>> ? 53? * Sparc.Solaris.dt_socket-transport of RawCommandLineLaunch >>>>>> ? 54? *???????? connector >>>>>> ? 55? * ================================================ >>>>>> >>>>>> Isn't this still somewhat true? It's still requires dt_socket, but >>>>>> no longer solaris-sparc. This is part of the reason I asked above >>>>>> to print which transports are attempted. I'm curious what the >>>>>> skipped transport is on Windows. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 4/9/20 2:43 PM, Igor Ignatyev wrote: >>>>>>> http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ >>>>>>>> 38 lines changed: 8 ins; 23 del; 7 mod; >>>>>>> Hi all, >>>>>>> >>>>>>> could you please review this small patch for >>>>>>> nsk/jdi/Argument/value/value004 test? >>>>>>> from JBS: >>>>>>>> nsk/jdi/Argument/value/value004 test has restrictions to be run >>>>>>>> only on solaris-sparc and w/ dt_socket transport, solaris-sparc >>>>>>>> restriction seems to be not valid any more. the test also should >>>>>>>> be updated to use skipped exception if there are no suitable >>>>>>>> connectors available. >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242471 >>>>>>> testing: the changed test on {linux,windows,macosx}-x64 and >>>>>>> solaris-sparcv9, w/ the test being skipped on windows-x64 >>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> -- Igor >>>>>> >>>>>> >>>>> >>>> >> > From martin.doerr at sap.com Mon Apr 13 18:32:08 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 13 Apr 2020 18:32:08 +0000 Subject: RFR (S) 8074292: nsk/jdb/kill/kill001: generateOopMap.cpp assert(bb->is_reachable()) failed In-Reply-To: References: Message-ID: Hi Coleen, thanks for implementing it for all platforms. PPC64: looks good. s390: The tm instruction produces a special condition code. z_brnaz should be used (please don't omit the 'a'). Tested interpreter safepoint polling by: jdk/bin/java -Xint -XX:-UseBiasedLocking -XX:+SafepointTimeout -XX:+SafepointALot -XX:+AbortVMOnSafepointTimeout -XX:SafepointTimeoutDelay=300 -XX:GuaranteedSafepointInterval=300 TestLoop (With some long running TestLoop.) This test crashed with z_brnz as expected, but worked with z_brnaz. Thanks and best regards, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > coleen.phillimore at oracle.com > Sent: Montag, 13. April 2020 16:34 > To: hotspot-dev developers ; > serviceability-dev at openjdk.java.net > Subject: RFR (S) 8074292: nsk/jdb/kill/kill001: generateOopMap.cpp > assert(bb->is_reachable()) failed > > Summary: Do not install async exceptions at_safepoint for each bytecode. > > See CR for a lot more details.? This change calls a new > InterpreterRuntime::at_safepoint_async_safe() which installs the async > exception in the interpreter at backward branches and returns.? This > uses safepoint polling code in the interpreter for each platform.? These > changes (cross) compile on platforms that Oracle doesn't support but I > don't know if they work. > > I'm not convinced the platform specific changes are necessary, because > calls to the runtime from many bytecodes will install the async > exception, so it's essentially installed "enough" for this deprecated > feature.? I tested the changes with *and* without the platform specific > changes with no failure, which included the jdb, jdi and jvmti > serviceability tests. > > This change also makes InterpreterRuntime::monitorexit a JRT_LEAF > bytecode. The code to check for exceptions is outside the runtime call. > I ran the JCK vm and lang tests on this change with no failure. > > Tested with tier1-6. > > open webrev at > http://cr.openjdk.java.net/~coleenp/2020/8074292.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8074292 > > Thanks, > Coleen From chris.plummer at oracle.com Mon Apr 13 18:42:26 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 13 Apr 2020 11:42:26 -0700 Subject: RFR(S/T) : 8242313 : use reproducible random in hotspot svc tests In-Reply-To: <9D4159AF-7248-4A5F-824E-3ABC26CBD970@oracle.com> References: <963A7599-45FD-421A-AB68-09188F290791@oracle.com> <9D4159AF-7248-4A5F-824E-3ABC26CBD970@oracle.com> Message-ID: Looks good. thanks, Chris On 4/13/20 10:36 AM, Igor Ignatyev wrote: > ping? > -- Igor > >> On Apr 8, 2020, at 10:21 AM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8242313/webrev.00 >>> 16 lines changed: 10 ins; 0 del; 6 mod; >> Hi all, >> >> could you please review the patch which updates hotspot/jtreg/serviceability tests in the same way as 8242310[1,2] updates compiler tests: >>> marks ... tests w/ randomness k/w and uses Utils.getRandomInstance() instead of Random w/ _random_ seeds where possible? To identify tests which should be marked, I've used both static (in a form of analyzing classes which directly or indirectly depend on Random/SecureRandom/ThreadLocalRandom) and dynamic (by instrumenting the said classes to log tests which called their 'next' methods) analyses. I've decided *not* to mark tests which use SecureRandom only via File.createTemp* b/c in all such cases temp files are not used as a source of randomness, but rather just a reliable way to get a new/empty file/dir. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8242313 >> webrev: http://cr.openjdk.java.net/~iignatyev/8242313/webrev.00 >> NB the patch depends on 8241707[3], which is currently under review[4]. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8242310 >> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037828.html >> [3] https://bugs.openjdk.java.net/browse/JDK-8241707 >> [4] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041300.html >> >> Thanks, >> -- Igor From coleen.phillimore at oracle.com Mon Apr 13 18:42:35 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 13 Apr 2020 14:42:35 -0400 Subject: RFR (S) 8074292: nsk/jdb/kill/kill001: generateOopMap.cpp assert(bb->is_reachable()) failed In-Reply-To: References: Message-ID: Hi Martin, Thank you for testing this, the correction, and the code review. Coleen On 4/13/20 2:32 PM, Doerr, Martin wrote: > Hi Coleen, > > thanks for implementing it for all platforms. > > PPC64: looks good. > > s390: The tm instruction produces a special condition code. z_brnaz should be used (please don't omit the 'a'). > > Tested interpreter safepoint polling by: > jdk/bin/java -Xint -XX:-UseBiasedLocking -XX:+SafepointTimeout -XX:+SafepointALot -XX:+AbortVMOnSafepointTimeout -XX:SafepointTimeoutDelay=300 -XX:GuaranteedSafepointInterval=300 TestLoop > > (With some long running TestLoop.) > > This test crashed with z_brnz as expected, but worked with z_brnaz. > > Thanks and best regards, > Martin > > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> coleen.phillimore at oracle.com >> Sent: Montag, 13. April 2020 16:34 >> To: hotspot-dev developers ; >> serviceability-dev at openjdk.java.net >> Subject: RFR (S) 8074292: nsk/jdb/kill/kill001: generateOopMap.cpp >> assert(bb->is_reachable()) failed >> >> Summary: Do not install async exceptions at_safepoint for each bytecode. >> >> See CR for a lot more details.? This change calls a new >> InterpreterRuntime::at_safepoint_async_safe() which installs the async >> exception in the interpreter at backward branches and returns.? This >> uses safepoint polling code in the interpreter for each platform.? These >> changes (cross) compile on platforms that Oracle doesn't support but I >> don't know if they work. >> >> I'm not convinced the platform specific changes are necessary, because >> calls to the runtime from many bytecodes will install the async >> exception, so it's essentially installed "enough" for this deprecated >> feature.? I tested the changes with *and* without the platform specific >> changes with no failure, which included the jdb, jdi and jvmti >> serviceability tests. >> >> This change also makes InterpreterRuntime::monitorexit a JRT_LEAF >> bytecode. The code to check for exceptions is outside the runtime call. >> I ran the JCK vm and lang tests on this change with no failure. >> >> Tested with tier1-6. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8074292.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8074292 >> >> Thanks, >> Coleen From chris.plummer at oracle.com Mon Apr 13 18:45:03 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 13 Apr 2020 11:45:03 -0700 Subject: RFR(S) 8235220: ClhsdbScanOops.java fails with sun.jvm.hotspot.types.WrongTypeException In-Reply-To: <27d01f05-c5e9-a976-910e-eddeab6ab547@oracle.com> References: <27d01f05-c5e9-a976-910e-eddeab6ab547@oracle.com> Message-ID: <468cdc7e-3826-07e1-214b-aecde7a9921e@oracle.com> Ping! Can I get one more review please. thanks, Chris On 4/9/20 10:21 PM, Ioi Lam wrote: > Hi Chris, > > Thanks for fixing this. It looks good to me. > > - Ioi > > On 4/9/20 9:44 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8235220 >> http://cr.openjdk.java.net/~cjplummer/8235220/webrev.00 >> >> First off, thanks to Ioi for tracking this one down and proposing the >> fix. >> >> The test is executing the clhsdb "scanoops" command, which scans the >> specified heap address range looking for objects of the specified >> type (or all objects if no type is specified). The test determines >> the address range by first using clhsdb "universe" to get the start >> and end of the eden space. scanoops then iterates over this entire >> range, calling RobustOopDeterminator.oopLooksValid() on each oop as >> it iterates over the range. The problem is eventually you'll end up >> past the initialized part of the heap. That causes >> VirtualBaseConstructor.findDynamicTypeForAddress() to return null, >> resulting in throwing a WrongTypeException. >> RobustOopDeterminator.oopLooksValid() should catch this exception and >> return false when it happens. >> >> The CR mentions a few different failure modes. This only fixes the >> WrongTypeException failure. The NullPointerException is only on OSX >> and I believe is the same as JDK-8241158 [1], which happens when >> dumping the heap, so it seems probable that it is also turning up >> when scanning part of the heap. I think this bug was preventing us >> from ever seeing the WrongTypeException on OSX. Then there also >> JDK-8230731 [2] on Windows, which seems to prevent ever seeing the >> WrongTypeException on Windows. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8241158 >> [2] https://bugs.openjdk.java.net/browse/JDK-8230731 >> >> thanks, >> >> Chris > From igor.ignatyev at oracle.com Mon Apr 13 19:35:12 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 13 Apr 2020 12:35:12 -0700 Subject: RFR(S/T) : 8242313 : use reproducible random in hotspot svc tests In-Reply-To: References: <963A7599-45FD-421A-AB68-09188F290791@oracle.com> <9D4159AF-7248-4A5F-824E-3ABC26CBD970@oracle.com> Message-ID: Thanks Chris, pushed. -- Igor > On Apr 13, 2020, at 11:42 AM, Chris Plummer wrote: > > Looks good. > > thanks, > > Chris > > On 4/13/20 10:36 AM, Igor Ignatyev wrote: >> ping? >> -- Igor >> >>> On Apr 8, 2020, at 10:21 AM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8242313/webrev.00 >>>> 16 lines changed: 10 ins; 0 del; 6 mod; >>> Hi all, >>> >>> could you please review the patch which updates hotspot/jtreg/serviceability tests in the same way as 8242310[1,2] updates compiler tests: >>>> marks ... tests w/ randomness k/w and uses Utils.getRandomInstance() instead of Random w/ _random_ seeds where possible? To identify tests which should be marked, I've used both static (in a form of analyzing classes which directly or indirectly depend on Random/SecureRandom/ThreadLocalRandom) and dynamic (by instrumenting the said classes to log tests which called their 'next' methods) analyses. I've decided *not* to mark tests which use SecureRandom only via File.createTemp* b/c in all such cases temp files are not used as a source of randomness, but rather just a reliable way to get a new/empty file/dir. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242313 >>> webrev: http://cr.openjdk.java.net/~iignatyev/8242313/webrev.00 >>> NB the patch depends on 8241707[3], which is currently under review[4]. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8242310 >>> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037828.html >>> [3] https://bugs.openjdk.java.net/browse/JDK-8241707 >>> [4] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041300.html >>> >>> Thanks, >>> -- Igor > From igor.ignatyev at oracle.com Mon Apr 13 19:35:32 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 13 Apr 2020 12:35:32 -0700 Subject: RFR(S) : 8242471 : remove "temporarily" restrictions of nsk/jdi/Argument/value/value004 In-Reply-To: References: <0aaca1c1-34c1-dd3b-92bb-d86c82860a81@oracle.com> <6E9E8D43-1FDF-4E14-AAAD-BBA2FA3BCA7A@oracle.com> <72d4adef-57bf-0473-933e-398b7224e6a4@oracle.com> Message-ID: Thanks Alex, pushed. -- Igor > On Apr 13, 2020, at 11:30 AM, Alex Menkov wrote: > > LGTM > > --alex > > On 04/13/2020 10:35, Igor Ignatyev wrote: >> sure. >> @alias, can I get a 2nd review for this patch? >> Thanks, >> -- Igor >>> On Apr 9, 2020, at 9:45 PM, Chris Plummer > wrote: >>> >>> Hi Igor, >>> >>> I think it's best to get another review. >>> >>> thanks, >>> >>> Chris >>> >>> On 4/9/20 8:49 PM, Igor Ignatev wrote: >>>> Thanks Chris! Would you consider this trivial or should I wait for another review? >>>> >>>> ? Igor >>>> >>>>> On Apr 9, 2020, at 8:35 PM, Chris Plummer wrote: >>>>> >>>>> ? >>>>> Hi Igor, >>>>> >>>>> The changes looks good. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 4/9/20 4:13 PM, Igor Ignatyev wrote: >>>>>> Hi Chris, >>>>>> >>>>>> I looked what transport got skipped on Windows, and it's dt_shmem, as I didn't see any reasons why this test should not be run w/ this transport, I looked deeper and I found the place which needs to be updated to make the test work w/ dt_shmem. so now the test doesn't skip any transports (and thus the removed warning isn't even partially true) and only skips connector other than c.s.j.RawCommandLineLaunch, to make it cleaner the test now logs the skipped connectors, e.g. on my mac, I'm getting the following in .jtr >>>>>>> skipping com.sun.jdi.CommandLineLaunch (defaults: home=/Users/iignatye/ws/jdk/jdk/build/macosx-x64/images/jdk, options=, main=, suspend=true, quote=", vmexec=java) >>>>>> >>>>>> I've retested the patch on the same platforms as before and now it passes on windows as well. >>>>>> >>>>>> incremental webrev: http://cr.openjdk.java.net/~iignatyev//8242471/webrev.0-1/index.html >>>>>> full webrev: http://cr.openjdk.java.net/~iignatyev//8242471/webrev.01/index.html >>>>>> >>>>>> Thanks, >>>>>> -- Igor >>>>>> >>>>>>> On Apr 9, 2020, at 3:15 PM, Chris Plummer > wrote: >>>>>>> >>>>>>> Hi Igor, >>>>>>> >>>>>>> 89 log.display("Connector's transport is: " + c.transport().name()); >>>>>>> >>>>>>> Would be nice if you printed each transport's name (even the skipped ones). That way when reading the log after getting SkippedException you can see which transports were attempted. >>>>>>> >>>>>>> You removed the following: >>>>>>> >>>>>>> 50 * ================================================ >>>>>>> 51 * WARNING: >>>>>>> 52 * Temporarily the test is prepared only for >>>>>>> 53 * Sparc.Solaris.dt_socket-transport of RawCommandLineLaunch >>>>>>> 54 * connector >>>>>>> 55 * ================================================ >>>>>>> >>>>>>> Isn't this still somewhat true? It's still requires dt_socket, but no longer solaris-sparc. This is part of the reason I asked above to print which transports are attempted. I'm curious what the skipped transport is on Windows. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 4/9/20 2:43 PM, Igor Ignatyev wrote: >>>>>>>> http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ >>>>>>>>> 38 lines changed: 8 ins; 23 del; 7 mod; >>>>>>>> Hi all, >>>>>>>> >>>>>>>> could you please review this small patch for nsk/jdi/Argument/value/value004 test? >>>>>>>> from JBS: >>>>>>>>> nsk/jdi/Argument/value/value004 test has restrictions to be run only on solaris-sparc and w/ dt_socket transport, solaris-sparc restriction seems to be not valid any more. the test also should be updated to use skipped exception if there are no suitable connectors available. >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242471 >>>>>>>> testing: the changed test on {linux,windows,macosx}-x64 and solaris-sparcv9, w/ the test being skipped on windows-x64 >>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8242471/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -- Igor >>>>>>> >>>>>>> >>>>>> >>>>> >>> From alexey.menkov at oracle.com Mon Apr 13 19:48:52 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 13 Apr 2020 12:48:52 -0700 Subject: RFR(S) 8235220: ClhsdbScanOops.java fails with sun.jvm.hotspot.types.WrongTypeException In-Reply-To: <468cdc7e-3826-07e1-214b-aecde7a9921e@oracle.com> References: <27d01f05-c5e9-a976-910e-eddeab6ab547@oracle.com> <468cdc7e-3826-07e1-214b-aecde7a9921e@oracle.com> Message-ID: <3d745605-f70e-b866-8d6a-67a5948d4b16@oracle.com> Looks good. --alex On 04/13/2020 11:45, Chris Plummer wrote: > Ping! Can I get one more review please. > > thanks, > > Chris > > On 4/9/20 10:21 PM, Ioi Lam wrote: >> Hi Chris, >> >> Thanks for fixing this. It looks good to me. >> >> - Ioi >> >> On 4/9/20 9:44 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8235220 >>> http://cr.openjdk.java.net/~cjplummer/8235220/webrev.00 >>> >>> First off, thanks to Ioi for tracking this one down and proposing the >>> fix. >>> >>> The test is executing the clhsdb "scanoops" command, which scans the >>> specified heap address range looking for objects of the specified >>> type (or all objects if no type is specified). The test determines >>> the address range by first using clhsdb "universe" to get the start >>> and end of the eden space. scanoops then iterates over this entire >>> range, calling RobustOopDeterminator.oopLooksValid() on each oop as >>> it iterates over the range. The problem is eventually you'll end up >>> past the initialized part of the heap. That causes >>> VirtualBaseConstructor.findDynamicTypeForAddress() to return null, >>> resulting in throwing a WrongTypeException. >>> RobustOopDeterminator.oopLooksValid() should catch this exception and >>> return false when it happens. >>> >>> The CR mentions a few different failure modes. This only fixes the >>> WrongTypeException failure. The NullPointerException is only on OSX >>> and I believe is the same as JDK-8241158 [1], which happens when >>> dumping the heap, so it seems probable that it is also turning up >>> when scanning part of the heap. I think this bug was preventing us >>> from ever seeing the WrongTypeException on OSX. Then there also >>> JDK-8230731 [2] on Windows, which seems to prevent ever seeing the >>> WrongTypeException on Windows. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8241158 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8230731 >>> >>> thanks, >>> >>> Chris >> > From chris.plummer at oracle.com Mon Apr 13 20:25:14 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 13 Apr 2020 13:25:14 -0700 Subject: RFR(S) 8235220: ClhsdbScanOops.java fails with sun.jvm.hotspot.types.WrongTypeException In-Reply-To: <3d745605-f70e-b866-8d6a-67a5948d4b16@oracle.com> References: <27d01f05-c5e9-a976-910e-eddeab6ab547@oracle.com> <468cdc7e-3826-07e1-214b-aecde7a9921e@oracle.com> <3d745605-f70e-b866-8d6a-67a5948d4b16@oracle.com> Message-ID: Thanks! On 4/13/20 12:48 PM, Alex Menkov wrote: > Looks good. > > --alex > > On 04/13/2020 11:45, Chris Plummer wrote: >> Ping! Can I get one more review please. >> >> thanks, >> >> Chris >> >> On 4/9/20 10:21 PM, Ioi Lam wrote: >>> Hi Chris, >>> >>> Thanks for fixing this. It looks good to me. >>> >>> - Ioi >>> >>> On 4/9/20 9:44 PM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8235220 >>>> http://cr.openjdk.java.net/~cjplummer/8235220/webrev.00 >>>> >>>> First off, thanks to Ioi for tracking this one down and proposing >>>> the fix. >>>> >>>> The test is executing the clhsdb "scanoops" command, which scans >>>> the specified heap address range looking for objects of the >>>> specified type (or all objects if no type is specified). The test >>>> determines the address range by first using clhsdb "universe" to >>>> get the start and end of the eden space. scanoops then iterates >>>> over this entire range, calling >>>> RobustOopDeterminator.oopLooksValid() on each oop as it iterates >>>> over the range. The problem is eventually you'll end up past the >>>> initialized part of the heap. That causes >>>> VirtualBaseConstructor.findDynamicTypeForAddress() to return null, >>>> resulting in throwing a WrongTypeException. >>>> RobustOopDeterminator.oopLooksValid() should catch this exception >>>> and return false when it happens. >>>> >>>> The CR mentions a few different failure modes. This only fixes the >>>> WrongTypeException failure. The NullPointerException is only on OSX >>>> and I believe is the same as JDK-8241158 [1], which happens when >>>> dumping the heap, so it seems probable that it is also turning up >>>> when scanning part of the heap. I think this bug was preventing us >>>> from ever seeing the WrongTypeException on OSX. Then there also >>>> JDK-8230731 [2] on Windows, which seems to prevent ever seeing the >>>> WrongTypeException on Windows. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8241158 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8230731 >>>> >>>> thanks, >>>> >>>> Chris >>> >> From chris.plummer at oracle.com Mon Apr 13 20:30:25 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 13 Apr 2020 13:30:25 -0700 Subject: RFR(XS) 8237250: pmap and pstack should do a better of making it clear that they are not supported on Mac OS X In-Reply-To: <99bca2cd-61ac-e1c7-17a0-f357edf03d65@oracle.com> References: <99bca2cd-61ac-e1c7-17a0-f357edf03d65@oracle.com> Message-ID: <98c4629a-b437-d0cd-1732-ce7f2434b07d@oracle.com> Ping! This one is pretty trivial. You don't really need to know anything about PMap and PStack to review. It's just cleaning up how they fail due due not being supported on OSX, and also adjusting the tests to detect the failure. thanks, Chris On 4/9/20 3:55 PM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8237250 > http://cr.openjdk.java.net/~cjplummer/8237250/webrev.01/index.html > > Details are in the CR. > > thanks, > > Chris From alexey.menkov at oracle.com Mon Apr 13 22:33:35 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 13 Apr 2020 15:33:35 -0700 Subject: RFR(XS) 8237250: pmap and pstack should do a better of making it clear that they are not supported on Mac OS X In-Reply-To: <98c4629a-b437-d0cd-1732-ce7f2434b07d@oracle.com> References: <99bca2cd-61ac-e1c7-17a0-f357edf03d65@oracle.com> <98c4629a-b437-d0cd-1732-ce7f2434b07d@oracle.com> Message-ID: <1199992b-f0c3-56fc-1937-be54d0b85c25@oracle.com> LGTM --alex On 04/13/2020 13:30, Chris Plummer wrote: > Ping! > > This one is pretty trivial. You don't really need to know anything about > PMap and PStack to review. It's just cleaning up how they fail due due > not being supported on OSX, and also adjusting the tests to detect the > failure. > > thanks, > > Chris > > On 4/9/20 3:55 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8237250 >> http://cr.openjdk.java.net/~cjplummer/8237250/webrev.01/index.html >> >> Details are in the CR. >> >> thanks, >> >> Chris > From serguei.spitsyn at oracle.com Mon Apr 13 22:49:19 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 13 Apr 2020 15:49:19 -0700 Subject: RFR(XS) 8237250: pmap and pstack should do a better of making it clear that they are not supported on Mac OS X In-Reply-To: <1199992b-f0c3-56fc-1937-be54d0b85c25@oracle.com> References: <99bca2cd-61ac-e1c7-17a0-f357edf03d65@oracle.com> <98c4629a-b437-d0cd-1732-ce7f2434b07d@oracle.com> <1199992b-f0c3-56fc-1937-be54d0b85c25@oracle.com> Message-ID: <8be9f516-52db-82c3-38a6-a72ea2b2a4f1@oracle.com> Hi Chris, LGTM++ Thanks, Serguei On 4/13/20 15:33, Alex Menkov wrote: > LGTM > > --alex > > On 04/13/2020 13:30, Chris Plummer wrote: >> Ping! >> >> This one is pretty trivial. You don't really need to know anything >> about PMap and PStack to review. It's just cleaning up how they fail >> due due not being supported on OSX, and also adjusting the tests to >> detect the failure. >> >> thanks, >> >> Chris >> >> On 4/9/20 3:55 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8237250 >>> http://cr.openjdk.java.net/~cjplummer/8237250/webrev.01/index.html >>> >>> Details are in the CR. >>> >>> thanks, >>> >>> Chris >> From chris.plummer at oracle.com Mon Apr 13 23:29:01 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 13 Apr 2020 16:29:01 -0700 Subject: RFR(XS) 8237250: pmap and pstack should do a better of making it clear that they are not supported on Mac OS X In-Reply-To: <8be9f516-52db-82c3-38a6-a72ea2b2a4f1@oracle.com> References: <99bca2cd-61ac-e1c7-17a0-f357edf03d65@oracle.com> <98c4629a-b437-d0cd-1732-ce7f2434b07d@oracle.com> <1199992b-f0c3-56fc-1937-be54d0b85c25@oracle.com> <8be9f516-52db-82c3-38a6-a72ea2b2a4f1@oracle.com> Message-ID: <39ce70d7-4157-8e0e-b9f9-8bf923c944dc@oracle.com> Thanks! On 4/13/20 3:49 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > LGTM++ > > Thanks, > Serguei > > > On 4/13/20 15:33, Alex Menkov wrote: >> LGTM >> >> --alex >> >> On 04/13/2020 13:30, Chris Plummer wrote: >>> Ping! >>> >>> This one is pretty trivial. You don't really need to know anything >>> about PMap and PStack to review. It's just cleaning up how they fail >>> due due not being supported on OSX, and also adjusting the tests to >>> detect the failure. >>> >>> thanks, >>> >>> Chris >>> >>> On 4/9/20 3:55 PM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8237250 >>>> http://cr.openjdk.java.net/~cjplummer/8237250/webrev.01/index.html >>>> >>>> Details are in the CR. >>>> >>>> thanks, >>>> >>>> Chris >>> > From david.holmes at oracle.com Tue Apr 14 02:49:37 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Apr 2020 12:49:37 +1000 Subject: RFR (S) 8074292: nsk/jdb/kill/kill001: generateOopMap.cpp assert(bb->is_reachable()) failed In-Reply-To: References: Message-ID: <6e38070c-f166-a0c2-8b8d-d698e5f5bcf3@oracle.com> Hi Coleen, On 14/04/2020 12:34 am, coleen.phillimore at oracle.com wrote: > Summary: Do not install async exceptions at_safepoint for each bytecode. I'm still not certain that we have to go this far to solve this problem, but it does sound like a relatively simple solution provided there are no unintended consequences. > See CR for a lot more details.? This change calls a new > InterpreterRuntime::at_safepoint_async_safe() which installs the async > exception in the interpreter at backward branches and returns.? This > uses safepoint polling code in the interpreter for each platform.? These > changes (cross) compile on platforms that Oracle doesn't support but I > don't know if they work. > > I'm not convinced the platform specific changes are necessary, because > calls to the runtime from many bytecodes will install the async > exception, so it's essentially installed "enough" for this deprecated > feature.? I tested the changes with *and* without the platform specific > changes with no failure, which included the jdb, jdi and jvmti > serviceability tests. I don't understand what you mean here. If the whole basis of this fix is "don't install async exceptions other than at backward branches and returns" then how is that implemented without the changes in the interpreter code? If this can be fixed just by adjusting the actual monitor code then I would much prefer that. It took me a while to get my head around the dispatch changes in interpreter code and even then I don't see how those changes only impact backward branches and returns ?? > > This change also makes InterpreterRuntime::monitorexit a JRT_LEAF > bytecode. The code to check for exceptions is outside the runtime call. > I ran the JCK vm and lang tests on this change with no failure. > > Tested with tier1-6. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8074292.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8074292 ./cpu/x86/interp_masm_x86.cpp It took me a long time to figure out how the new logic worked compared to the old logic. Even then I'm unclear about the effective recursive dispatch path: dispatch_base(generate_poll=true) -> dispatch_via -> dispatch_base(generate_poll=false) - does it work okay with VerifyActivationFrameSize? It seems a rather convoluted way to effectively just execute: 858 lea(rscratch1, ExternalAddress((address)table)); 859 jmp(Address(rscratch1, rbx, Address::times_8)); --- src/hotspot/share/interpreter/interpreterRuntime.cpp How were you able to drop this code: 791 if (elem == NULL || h_obj()->is_unlocked()) { 792 THROW(vmSymbols::java_lang_IllegalMonitorStateException()); 793 } ? and this: 798 #ifdef ASSERT 799 thread->last_frame().interpreter_frame_verify_monitor(elem); 800 #endif ? Thanks, David > Thanks, > Coleen > From richard.reingruber at sap.com Tue Apr 14 08:29:56 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 14 Apr 2020 08:29:56 +0000 Subject: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump In-Reply-To: References: <01361a9d-2855-db67-a176-73731fada08f@oracle.com> <0c687e55-ed91-e606-28a7-f9aef745ed8d@oracle.com> <490d58f7-7adc-00aa-b504-0ac284fe7eb5@oracle.com> <0343dfac-61f7-1b1c-ee96-bdee130578ad@oracle.com> Message-ID: Hi Ralf, thanks for providing this enhancement to parallel gzip-compress heap dumps! I reckon it's safe to say that the coding is sophisticated. It would be awesome if you could sketch the idea of how HeapDumper, DumpWriter and CompressionBackend work together to produce the gzipped dump in a source code comment. Just enough to get started if somebody should ever have to track down a bug -- an unlikely event, I know ;) Please find the details of my review below. Thanks, Richard. // Not Reviewer -- ### src/hotspot/share/services/diagnosticCommand.cpp 510 _gzip_level("-gz-level", "The compression level from 0 (store) to 9 (best) when writing in gzipped format.", 511 "INT", "FALSE", "1") { "FALSE" should be probably false. ### src/hotspot/share/services/diagnosticCommand.hpp Ok. ### src/hotspot/share/services/heapDumper.cpp 390: Typo: initized 415: Typo: GZipComressor 477: Could you please add a comment, how the "HPROF BLOCKSIZE" comment is helpful? 539: Member variables of WriteWork are missing the '_' prefix. 546: Just a comment: WriteWork::in_max is actually a compile time constant. Would be nice if it could be declared so. One could use templates for this, but then my favourite ide (eclipse cdt) doesn't show me references and call hierarchies anymore. So I don't think it is worth it. 591: Typo: Removes the first element. Returns NULL is empty. 663: _writer, _compressor, _lock could be const. 762: assert(_active, "Must be active"); It appears to me that the assertion would fail, if an error occurred creating the CompressionBackend. 767: I think _current->in_used doesn't take the final 9 bytes into account that are written in DumperSupport::end_of_dump() after the last dump segment has been finished. You could call get_new_buffer() instead of the if clause. 903: Typo: Check if we don not waste more than _max_waste 1064: DumpWriter::DumpWriter() There doesn't seem to be enough error handling if _buffer cannot be allocated. E.g. DumpWriter::write_raw() at line 1091 will enter an endless loop. 2409: A comment, why Shenandoah is not supported, would be good. In general I'd say it is good and natural to use the GC work threads. ### src/hotspot/share/services/heapDumper.hpp Ok. ### src/java.base/share/native/libzip/zip_util.c I'm not familiar with zlib, but here are my .02? :) 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() performance wise. But have you measured the performance gain? In other words: is it worth it? :) 1655: The result of deflateBound() seems to depend on the header comment, which is not given here. Could this be an issue, because ZIP_GZip_Fully() can take a comment? 1658: deflateEnd() should not be called if deflateInit2Wrapper() failed. I think this can lead otherwise to a double free() call. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java 66: Maybe additionally check the exit value? 73: It's unclear to me, why this fails. Because the dump already exists? Because the level is invalid? Reading the comment I'd expect success, not failure. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestEpsilon.java Ok. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestShenandoah.java Ok. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestZ.java Ok. ### test/lib/jdk/test/lib/hprof/parser/GzipRandomAccess.java Ok. ### test/lib/jdk/test/lib/hprof/parser/HprofReader.java Ok. ### test/lib/jdk/test/lib/hprof/parser/Reader.java 93: is the created GzipRandomAccess instance closed somewhere? -----Original Message----- From: serviceability-dev On Behalf Of Schmelter, Ralf Sent: Freitag, 13. M?rz 2020 12:43 To: Ioi Lam ; Langer, Christoph ; Yasumasa Suenaga ; serguei.spitsyn at oracle.com; hotspot-runtime-dev at openjdk.java.net runtime Cc: serviceability-dev at openjdk.java.net Subject: [CAUTION] RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump Hi, I have updated the webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.1/ It has the following significant changes: - The jcmd now uses two separate flags. The -gz flag is now a boolean flag which toggles the compression on/off. And the new -gz-level flag can be used to change the compression level. If tried to change the jlong flag coding to allow the old behavior (only one flag, which acts both as a boolean flag and a jlong flag), but decided against it, since it changes the semantic of a jlong flag. And I don't expect the -gz-level flag to be used all that much. - I no longer use my own threads. Instead I use the WorkGang returned from CollectedHeap:: get_safepoint_workers(). This works fine, apart from Shenandoah GC, which runs into assertions when calling the CollectedHeap::object_iterate() method from a worker thread. I'm not sure if the assertion is too strong, but since the GC is currently experimental, I switch back to single threading in this case (as would be the case for serial GC or epsilon GC). Using the worker threads removes the problems the original code had regarding destruction of the monitor used. - The reported number of bytes is now the one written to disk. Best regards, Ralf -----Original Message----- From: Ioi Lam Sent: Dienstag, 25. Februar 2020 18:03 To: Langer, Christoph ; Schmelter, Ralf ; Yasumasa Suenaga ; serguei.spitsyn at oracle.com; hotspot-runtime-dev at openjdk.java.net runtime Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump Hi Christoph, This sounds fair. I will remove my objection :-) Thanks - Ioi From magnus.ihse.bursie at oracle.com Tue Apr 14 09:24:24 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Apr 2020 11:24:24 +0200 Subject: Ping: Re: RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent In-Reply-To: References: <8d884fcb-f424-1b54-7ece-5260037b2843@oracle.com> <01f77be3-e7d2-a051-80ab-e81c83922cf6@oracle.com> Message-ID: <6c008d7c-db6a-e9ad-5b49-e90703e19bad@oracle.com> Hi, Can I please get a review for this, simplified version of the patch? This only contain trivial changes, like this: - private List objects; // ArrayList + private List objects; Basically all changes are to the container types List or Map (and a few changes from Class to Class). If the list of all the files look horrible in the webrev, have a look at the patch file instead, it is easier to scroll through and check the changes: http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.02/open.patch /Magnus On 2020-03-30 16:25, Magnus Ihse Bursie wrote: > > > On 2020-03-25 20:52, Chris Plummer wrote: >> Hi Magus, >> >> I haven't looked at the changes yet, other to see that there are many >> files touched, but after reading below (and only partly understanding >> since I don't know this area well), I was wondering if this issue >> wouldn't be better served with multiple passes made to fix the >> warnings. Start with a straight forward one where you are maybe only >> making one or two types of changes, but that affect a large number of >> files and don't cascade into other more complicated changes. This >> will get a lot of the noise out of the way, and then we can focus on >> some of the harder issues you bring up below. > Ok, I did just this. Here is an updated webrev. It contain the bulk of > the changes, but all changes are -- I dare not say trivially obvious, > but at least no-brainers. Hopefully it should be easier to review so I > can get this pushed and out of the way. > > This also means that it is not possible to turn on the warning just yet. > > http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.02 > > > /Magnus >> >> As for testing, I think the following list will capture all of them, >> but can't say for sure: >> >> open/test/hotspot/jtreg/serviceability/sa >> open/test/hotspot/jtreg/resourcehogs/serviceability/sa >> open/test/jdk/sun/tools/jhsdb >> open/test/jdk/sun/tools/jstack >> open/test/jdk/sun/tools/jmap >> open/test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >> >> open/test/hotspot/jtreg/compiler/ciReplay/TestSAClient.java >> open/test/hotspot/jtreg/compiler/ciReplay/TestSAServer.java >> >> Chris >> >> On 3/25/20 12:29 PM, Magnus Ihse Bursie wrote: >>> With the recent fixes in JDK-8241310, JDK-8237746 and JDK-8241073, >>> and the upcoming fixes to remove the deprecated nashorn and jdk.rmi, >>> the JDK build is very close to producing no warnings when compiling >>> the Java classes. >>> >>> The one remaining sinner is jdk.hotspot.agent. Most of the warnings >>> here are turned off, but unchecked and deprecation cannot be >>> completely silenced. >>> >>> Since the poor agent does not seem to receive much love nowadays, I >>> took it upon myself to fix these warnings, so we can finally get a >>> quiet build. >>> >>> I started to address the unchecked warnings. Unfortunately, this was >>> a much bigger task than I anticipated. I had to generify most of the >>> module. On the plus side, the code is so much better now. And most >>> of the changes were trivial, just tedious. >>> >>> There are a few places were I'm not entirely happy with the current >>> solution, and that at least merits some discussion. >>> >>> I have resorted to @SuppressWarnings in four classes: ciMethodData, >>> MethodData, TableModelComparator and VirtualBaseConstructor. All of >>> them has in common that they are doing slightly fishy things with >>> classes in collections. I'm not entirely sure they are bug-free, but >>> this patch leaves the behavior untouched. I did some efforts to sort >>> out the logic, but it turned out to be too hairy for me to fix, and >>> it will probably require more substantial changes to the workings of >>> the code. >>> >>> To make the code valid, I have moved ConstMethod to extend Metadata >>> instead of VMObject. My understanding is that this is benign (and >>> likely intended), but I really need for someone who knows the code >>> to confirm this. I have also added a FIXME to signal this. I'll >>> remove the FIXME as soon as I get confirmation that this is OK. >>> (The reason for this is the following piece of code from >>> Metadata.java: metadataConstructor.addMapping("ConstMethod", >>> ConstMethod.class)) >>> >>> In ObjectListPanel, there is some code that screams "dead" with this >>> change. I added a FIXME to point this out: >>> ??? for (Iterator iter = elements.iterator(); iter.hasNext(); ) { >>> ????? if (iter.next() instanceof Array) { >>> ??????? // FIXME: Does not seem possible to happen >>> ??????? hasArrays = true; >>> ??????? return; >>> ????? } >>> It seems that if you start pulling this thread, even more dead code >>> will unravel, so I'm not so eager to touch this in the current >>> patch. But I can remove the FIXME if you want. >>> >>> My first iteration of this patch tried to generify the IntervalTree >>> and related class hierarchy. However, this turned out to be >>> impossible due to some weird usage in AnnotatedMemoryPanel, where >>> there seemed to be confusion as to whether the tree stored >>> Annotations or Addresses. I'm not entirely convinced the code is >>> correct, it certainly looked and smelled very fishy. However, I >>> reverted these changes since I could not get them to work due to >>> this, and it was not needed for the goal of just getting rid of the >>> warning. >>> >>> Finally, I have done no testing apart from verifying that it builds. >>> Please advice on suitable tests to run. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241618 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.01 >>> >>> /Magnus >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue Apr 14 11:04:59 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Apr 2020 13:04:59 +0200 Subject: RFR: JDK-8242629 Remove references to deprecated java.util.Observer and Observable Message-ID: As a first step towards fixing deprecation warnings in SA, all the references (200+) to the deprecated java.util.Observer and Observable needs to be fixed, otherwise all other changes will drown in this one. This solution is the result of the preceding discussions in serviceability-dev. That means that most of the change consists of adding an explicit import like this: import sun.jvm.hotspot.utilities.Observable; import sun.jvm.hotspot.utilities.Observer; to override the general java.util.* import that was already present in all (or almost all) files, and make sun.jvm.hotspot.utilities.Observable and Observer extend the java.util versions but with deprecation warnings disabled. It turned out however, that this simplest approach did not work fully. Since the interface java.util.Observer had the single method "void update(java.util.Observable o, Object arg)" it did not help to create a new interface sun.jvm.hotspot.utilities.Observer that extended java.util.Observer. I did not observe this issue in my PoC webrev that I posted during the discussion. :-( Instead, for Observer, I had just created a new interface with the same method, but that uses sun.jvm.hotspot.utilities.Observable instead of java.util.Observable. The end effect is the same -- the only change needed to most files is an added import, we get rid of the deprecation warnings, and we did not have to copy any significant amount of code from java.util. I now hope this is acceptable by all. Bug: https://bugs.openjdk.java.net/browse/JDK-8242629 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01 (When reading the patch, I recommend looking at the patch file http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01/open.patch instead of individually checking the files in the webrev.) /Magnus From coleen.phillimore at oracle.com Tue Apr 14 12:36:13 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Apr 2020 08:36:13 -0400 Subject: RFR (S) 8074292: nsk/jdb/kill/kill001: generateOopMap.cpp assert(bb->is_reachable()) failed In-Reply-To: <6e38070c-f166-a0c2-8b8d-d698e5f5bcf3@oracle.com> References: <6e38070c-f166-a0c2-8b8d-d698e5f5bcf3@oracle.com> Message-ID: <1e3d4907-d54a-df0e-e0d3-8bbda8c5394a@oracle.com> On 4/13/20 10:49 PM, David Holmes wrote: > Hi Coleen, > > On 14/04/2020 12:34 am, coleen.phillimore at oracle.com wrote: >> Summary: Do not install async exceptions at_safepoint for each bytecode. > > I'm still not certain that we have to go this far to solve this > problem, but it does sound like a relatively simple solution provided > there are no unintended consequences. > >> See CR for a lot more details.? This change calls a new >> InterpreterRuntime::at_safepoint_async_safe() which installs the >> async exception in the interpreter at backward branches and returns.? >> This uses safepoint polling code in the interpreter for each >> platform.? These changes (cross) compile on platforms that Oracle >> doesn't support but I don't know if they work. >> >> I'm not convinced the platform specific changes are necessary, >> because calls to the runtime from many bytecodes will install the >> async exception, so it's essentially installed "enough" for this >> deprecated feature.? I tested the changes with *and* without the >> platform specific changes with no failure, which included the jdb, >> jdi and jvmti serviceability tests. > > I don't understand what you mean here. If the whole basis of this fix > is "don't install async exceptions other than at backward branches and > returns" then how is that implemented without the changes in the > interpreter code? > > If this can be fixed just by adjusting the actual monitor code then I > would much prefer that. It took me a while to get my head around the > dispatch changes in interpreter code and even then I don't see how > those changes only impact backward branches and returns ?? You have to read the comments in the bug again.? There *is* special code to not install the async exception in the monitorexit code. That is not enough to prevent this bug.? You can also read the old bug report you linked to this one. The interpreter code dispatch_next passes "true" if it's a backwards branch, that's how it can tell. My point was that there are enough code paths that install async exceptions *other than monitorenter and monitorexit* that maybe it's not necessary to install them at backwards branches and returns.? I suppose someone could construct a test case to show otherwise. > >> >> This change also makes InterpreterRuntime::monitorexit a JRT_LEAF >> bytecode. The code to check for exceptions is outside the runtime >> call. I ran the JCK vm and lang tests on this change with no failure. >> >> Tested with tier1-6. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8074292.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8074292 > > ./cpu/x86/interp_masm_x86.cpp > > It took me a long time to figure out how the new logic worked compared > to the old logic. Even then I'm unclear about the effective recursive > dispatch path: dispatch_base(generate_poll=true) -> dispatch_via -> > dispatch_base(generate_poll=false) - does it work okay with > VerifyActivationFrameSize? It seems a rather convoluted way to > effectively just execute: > > ?858?? lea(rscratch1, ExternalAddress((address)table)); > ?859?? jmp(Address(rscratch1, rbx, Address::times_8)); I could test it with VerifyActivationFrameSize.? Or I could just add the two instructions per platform.? I mostly copied the code in generate_safept_entry_for.? It might be better to just copy the instructions. > > --- > > src/hotspot/share/interpreter/interpreterRuntime.cpp > > How were you able to drop this code: > > 791?? if (elem == NULL || h_obj()->is_unlocked()) { > 792 THROW(vmSymbols::java_lang_IllegalMonitorStateException()); > 793?? } > > ? > ?and this: The caller throws the exception for these cases. > > 798 #ifdef ASSERT > 799 thread->last_frame().interpreter_frame_verify_monitor(elem); > 800 #endif > This seemed redundant. Coleen > ? > > Thanks, > David > >> Thanks, >> Coleen >> From coleen.phillimore at oracle.com Tue Apr 14 12:44:28 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Apr 2020 08:44:28 -0400 Subject: RFR: JDK-8242629 Remove references to deprecated java.util.Observer and Observable In-Reply-To: References: Message-ID: <9baf7a96-ef3b-d8ca-1e87-02d1a8245388@oracle.com> This looks good to me since we can't remove this.? The patch complains that for your Observer.java: \ No newline at end of file Thanks, Coleen On 4/14/20 7:04 AM, Magnus Ihse Bursie wrote: > As a first step towards fixing deprecation warnings in SA, all the > references (200+) to the deprecated java.util.Observer and Observable > needs to be fixed, otherwise all other changes will drown in this one. > > This solution is the result of the preceding discussions in > serviceability-dev. That means that most of the change consists of > adding an explicit import like this: > > import sun.jvm.hotspot.utilities.Observable; > import sun.jvm.hotspot.utilities.Observer; > > to override the general java.util.* import that was already present in > all (or almost all) files, and make > sun.jvm.hotspot.utilities.Observable and Observer extend the java.util > versions but with deprecation warnings disabled. > > It turned out however, that this simplest approach did not work fully. > Since the interface java.util.Observer had the single method "void > update(java.util.Observable o, Object arg)" it did not help to create > a new interface sun.jvm.hotspot.utilities.Observer that extended > java.util.Observer. I did not observe this issue in my PoC webrev that > I posted during the discussion. :-( > > Instead, for Observer, I had just created a new interface with the > same method, but that uses sun.jvm.hotspot.utilities.Observable > instead of java.util.Observable. > > The end effect is the same -- the only change needed to most files is > an added import, we get rid of the deprecation warnings, and we did > not have to copy any significant amount of code from java.util. > > I now hope this is acceptable by all. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242629 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01 > > (When reading the patch, I recommend looking at the patch file > http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01/open.patch > instead of individually checking the files in the webrev.) > > /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue Apr 14 12:55:59 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Apr 2020 14:55:59 +0200 Subject: RFR: JDK-8242629 Remove references to deprecated java.util.Observer and Observable In-Reply-To: <9baf7a96-ef3b-d8ca-1e87-02d1a8245388@oracle.com> References: <9baf7a96-ef3b-d8ca-1e87-02d1a8245388@oracle.com> Message-ID: On 2020-04-14 14:44, coleen.phillimore at oracle.com wrote: > > This looks good to me since we can't remove this. Thanks for your review! Does jdk.hotspot.agent follow the Hotspot review rules requiring two Reviewers? > The patch complains that for your Observer.java: > > \ No newline at end of file Yeah, I just noticed that. :-( I'll fix that before pushing. /Magnus > > Thanks, > Coleen > > On 4/14/20 7:04 AM, Magnus Ihse Bursie wrote: >> As a first step towards fixing deprecation warnings in SA, all the >> references (200+) to the deprecated java.util.Observer and Observable >> needs to be fixed, otherwise all other changes will drown in this one. >> >> This solution is the result of the preceding discussions in >> serviceability-dev. That means that most of the change consists of >> adding an explicit import like this: >> >> import sun.jvm.hotspot.utilities.Observable; >> import sun.jvm.hotspot.utilities.Observer; >> >> to override the general java.util.* import that was already present >> in all (or almost all) files, and make >> sun.jvm.hotspot.utilities.Observable and Observer extend the >> java.util versions but with deprecation warnings disabled. >> >> It turned out however, that this simplest approach did not work >> fully. Since the interface java.util.Observer had the single method >> "void update(java.util.Observable o, Object arg)" it did not help to >> create a new interface sun.jvm.hotspot.utilities.Observer that >> extended java.util.Observer. I did not observe this issue in my PoC >> webrev that I posted during the discussion. :-( >> >> Instead, for Observer, I had just created a new interface with the >> same method, but that uses sun.jvm.hotspot.utilities.Observable >> instead of java.util.Observable. >> >> The end effect is the same -- the only change needed to most files is >> an added import, we get rid of the deprecation warnings, and we did >> not have to copy any significant amount of code from java.util. >> >> I now hope this is acceptable by all. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8242629 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01 >> >> (When reading the patch, I recommend looking at the patch file >> http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01/open.patch >> instead of individually checking the files in the webrev.) >> >> /Magnus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue Apr 14 13:08:58 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Apr 2020 06:08:58 -0700 Subject: RFR: JDK-8242629 Remove references to deprecated java.util.Observer and Observable In-Reply-To: References: Message-ID: <9f1ba2dc-cffa-2d4f-fd99-535189666941@oracle.com> Hello Magnus, I'll let someone else judge the validity of the approach, though I think it seems ok. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java: Double imports. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java: Triple imports. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/MethodHandlesAdapterBlob.java: Double imports. /Erik On 2020-04-14 04:04, Magnus Ihse Bursie wrote: > As a first step towards fixing deprecation warnings in SA, all the > references (200+) to the deprecated java.util.Observer and Observable > needs to be fixed, otherwise all other changes will drown in this one. > > This solution is the result of the preceding discussions in > serviceability-dev. That means that most of the change consists of > adding an explicit import like this: > > import sun.jvm.hotspot.utilities.Observable; > import sun.jvm.hotspot.utilities.Observer; > > to override the general java.util.* import that was already present in > all (or almost all) files, and make > sun.jvm.hotspot.utilities.Observable and Observer extend the java.util > versions but with deprecation warnings disabled. > > It turned out however, that this simplest approach did not work fully. > Since the interface java.util.Observer had the single method "void > update(java.util.Observable o, Object arg)" it did not help to create > a new interface sun.jvm.hotspot.utilities.Observer that extended > java.util.Observer. I did not observe this issue in my PoC webrev that > I posted during the discussion. :-( > > Instead, for Observer, I had just created a new interface with the > same method, but that uses sun.jvm.hotspot.utilities.Observable > instead of java.util.Observable. > > The end effect is the same -- the only change needed to most files is > an added import, we get rid of the deprecation warnings, and we did > not have to copy any significant amount of code from java.util. > > I now hope this is acceptable by all. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242629 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01 > > (When reading the patch, I recommend looking at the patch file > http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01/open.patch > instead of individually checking the files in the webrev.) > > /Magnus From paul.sandoz at oracle.com Tue Apr 14 18:51:44 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 14 Apr 2020 11:51:44 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> Message-ID: <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> Looks good to me (not familiar with all the code areas. Minor suggestion: MethodHandles.java 1811 * ASCII periods. For the instance of {@link java.lang.Class} representing {@code C}: 1812 *
    1813 *
  • {@link Class#getName()} returns the string {@code GN + "/" + }, 1814 * even though this is not a valid binary class or interface name.
    • 1815 *
  • {@link Class#descriptorString()} returns the string 1816 * {@code "L" + N + ";" + "/" + }, 1817 * even though this is not a valid type descriptor name.
    • 1818 *
Add another bullet: ? even though this is not a valid type descriptor name; and - therefore {@link Class#describeConstable} returns an empty {@code Optional}. ? ? Paul. > On Apr 11, 2020, at 8:13 PM, Mandy Chung wrote: > > Please review the delta patch: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/ > > Incremental specdiff: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html > This is to follow a discussion [1] on Class::descriptorString and MethodType::descriptorString for hidden classes. The proposal is to define the descriptor string for a hidden class of this form: > "L" + N + ";" + "/" + > > The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and `MethodType::descriptorString` are updated to return the descriptor of this form for a hidden class. To support hidden class, `java.lang.invoke.TypeDescriptor` spec is revised such that a `TypeDescriptor` object can represent an entity that may not be described in nominal form. This change affects JVM TI, JDWP and JDI. The spec change includes a couple other JVM TI and java.instrument spec clarification w.r.t. hidden classes that Serguei has been working on. > > > > Mandy > [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html > > ---------------- > As a record, the above patch is applied on the top: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06/ > > webrev.06 includes the following changes that have been reviewed: > 1. rename "weak hidden" and Klass::is_hidden_weak to is_non_strong_hidden > 2. remove unused `setImplMethod` method from lambda proxy class > 3. include Serguei's patch to fix JDK-8242166: regression in JDI ClassUnload events > 4. drop the uniqueness guarantee of the suffix of the hidden class's name > > On 3/31/20 8:01 PM, Mandy Chung wrote: >> Thanks to the review feedbacks. >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >> Delta between webrev.03 and webrev.04: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ >> >> Summary of changes is: >> 1. Update javac to retain the previous behavior when compiling to target release <= 14 where lambda proxy class is not a nestmate >> 2. Rename Class::isHiddenClass to Class::isHidden >> 3. Address Joe's feedback on the CSR to document the behavior of the relevant methods in java.lang.Class for hidden classes >> 4. Add test case for unloadable class with nest host error >> 5. Add test cases for hidden classes with different kinds of class or interface >> 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class" >> 7. Small changes in response to Remi, Coleen, Paul's review comments >> 8. Fix copyright headers >> 9. Fix @modules in tests >> >> Most of the changes above have also been reviewed as separate patches. >> >> Thanks >> Mandy >> >> On 3/26/20 4:57 PM, Mandy Chung wrote: >>> Please review the implementation of JEP 371: Hidden Classes. The main changes are in core-libs and hotspot runtime area. Small changes are made in javac, VM compiler (intrinsification of Class::isHiddenClass), JFR, JDI, and jcmd. CSR [1]has been reviewed and is in the finalized state (see specdiff and javadoc below for reference). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >>> >>> javadoc/specdiff >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >>> >>> JVMS 5.4.4 change: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >>> >>> CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8238359 >>> >>> Thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 >> > From serguei.spitsyn at oracle.com Tue Apr 14 19:05:41 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Apr 2020 12:05:41 -0700 Subject: RFR: JDK-8242629 Remove references to deprecated java.util.Observer and Observable In-Reply-To: References: Message-ID: Hi Magnus, This looks okay to me unless there is a better solution. Thanks, Serguei On 4/14/20 04:04, Magnus Ihse Bursie wrote: > As a first step towards fixing deprecation warnings in SA, all the > references (200+) to the deprecated java.util.Observer and Observable > needs to be fixed, otherwise all other changes will drown in this one. > > This solution is the result of the preceding discussions in > serviceability-dev. That means that most of the change consists of > adding an explicit import like this: > > import sun.jvm.hotspot.utilities.Observable; > import sun.jvm.hotspot.utilities.Observer; > > to override the general java.util.* import that was already present in > all (or almost all) files, and make > sun.jvm.hotspot.utilities.Observable and Observer extend the java.util > versions but with deprecation warnings disabled. > > It turned out however, that this simplest approach did not work fully. > Since the interface java.util.Observer had the single method "void > update(java.util.Observable o, Object arg)" it did not help to create > a new interface sun.jvm.hotspot.utilities.Observer that extended > java.util.Observer. I did not observe this issue in my PoC webrev that > I posted during the discussion. :-( > > Instead, for Observer, I had just created a new interface with the > same method, but that uses sun.jvm.hotspot.utilities.Observable > instead of java.util.Observable. > > The end effect is the same -- the only change needed to most files is > an added import, we get rid of the deprecation warnings, and we did > not have to copy any significant amount of code from java.util. > > I now hope this is acceptable by all. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242629 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01 > > (When reading the patch, I recommend looking at the patch file > http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01/open.patch > instead of individually checking the files in the webrev.) > > /Magnus From chris.plummer at oracle.com Tue Apr 14 19:13:27 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 14 Apr 2020 12:13:27 -0700 Subject: RFR: JDK-8242629 Remove references to deprecated java.util.Observer and Observable In-Reply-To: References: Message-ID: Hi Magnus, Some minor mistakes below, but otherwise looks good. Also copyrights need updating. I don't need to see another webrev. thanks, Chris --- old/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/MethodHandlesAdapterBlob.java 2020-04-14 12:47:05.098156117 +0200 +++ new/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/MethodHandlesAdapterBlob.java 2020-04-14 12:47:04.774156119 +0200 @@ -28,6 +28,10 @@ ?import sun.jvm.hotspot.debugger.*; ?import sun.jvm.hotspot.runtime.*; ?import sun.jvm.hotspot.types.*; +import sun.jvm.hotspot.utilities.Observable; +import sun.jvm.hotspot.utilities.Observer; +import sun.jvm.hotspot.utilities.Observable; +import sun.jvm.hotspot.utilities.Observer; --- old/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java 2020-04-14 12:48:16.314155591 +0200 +++ new/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java 2020-04-14 12:48:15.962155594 +0200 @@ -33,6 +33,12 @@ ?import sun.jvm.hotspot.runtime.*; ?import sun.jvm.hotspot.types.*; ?import sun.jvm.hotspot.utilities.*; +import sun.jvm.hotspot.utilities.Observable; +import sun.jvm.hotspot.utilities.Observer; +import sun.jvm.hotspot.utilities.Observable; +import sun.jvm.hotspot.utilities.Observer; +import sun.jvm.hotspot.utilities.Observable; +import sun.jvm.hotspot.utilities.Observer; --- old/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java 2020-04-14 12:49:58.998154834 +0200 +++ new/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java 2020-04-14 12:49:58.674154836 +0200 @@ -29,6 +29,10 @@ ?import sun.jvm.hotspot.runtime.*; ?import sun.jvm.hotspot.oops.*; ?import sun.jvm.hotspot.types.*; +import sun.jvm.hotspot.utilities.Observable; +import sun.jvm.hotspot.utilities.Observer; +import sun.jvm.hotspot.utilities.Observable; +import sun.jvm.hotspot.utilities.Observer; +++ new/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/Observable.java 2020-04-14 12:50:10.634154748 +0200 ... \ No newline at end of file On 4/14/20 4:04 AM, Magnus Ihse Bursie wrote: > As a first step towards fixing deprecation warnings in SA, all the > references (200+) to the deprecated java.util.Observer and Observable > needs to be fixed, otherwise all other changes will drown in this one. > > This solution is the result of the preceding discussions in > serviceability-dev. That means that most of the change consists of > adding an explicit import like this: > > import sun.jvm.hotspot.utilities.Observable; > import sun.jvm.hotspot.utilities.Observer; > > to override the general java.util.* import that was already present in > all (or almost all) files, and make > sun.jvm.hotspot.utilities.Observable and Observer extend the java.util > versions but with deprecation warnings disabled. > > It turned out however, that this simplest approach did not work fully. > Since the interface java.util.Observer had the single method "void > update(java.util.Observable o, Object arg)" it did not help to create > a new interface sun.jvm.hotspot.utilities.Observer that extended > java.util.Observer. I did not observe this issue in my PoC webrev that > I posted during the discussion. :-( > > Instead, for Observer, I had just created a new interface with the > same method, but that uses sun.jvm.hotspot.utilities.Observable > instead of java.util.Observable. > > The end effect is the same -- the only change needed to most files is > an added import, we get rid of the deprecation warnings, and we did > not have to copy any significant amount of code from java.util. > > I now hope this is acceptable by all. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242629 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01 > > (When reading the patch, I recommend looking at the patch file > http://cr.openjdk.java.net/~ihse/JDK-8242629-fix-SA-Observer/webrev.01/open.patch > instead of individually checking the files in the webrev.) > > /Magnus From chris.plummer at oracle.com Tue Apr 14 21:23:37 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 14 Apr 2020 14:23:37 -0700 Subject: Ping: Re: RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent In-Reply-To: <6c008d7c-db6a-e9ad-5b49-e90703e19bad@oracle.com> References: <8d884fcb-f424-1b54-7ece-5260037b2843@oracle.com> <01f77be3-e7d2-a051-80ab-e81c83922cf6@oracle.com> <6c008d7c-db6a-e9ad-5b49-e90703e19bad@oracle.com> Message-ID: <531767b2-1f90-dcb1-95a8-8fe5af4483bd@oracle.com> An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Tue Apr 14 22:01:55 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 14 Apr 2020 15:01:55 -0700 Subject: RFR[S] 8241158 SA TestHeapDumpForInvokeDynamic.java fails when CDS archive is relocated Message-ID: <53af11d5-830d-678c-7eb8-e97875c01770@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8241158 http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ This is a bug in the CDS relocation code. When -XX:ArchiveRelocationMode=1 is specified, the CDS archive is mapped to an address picked by the OS (instead of the default address 0x800000000). As a result, we need to patch the native Klass* pointers inside java.lang.Class instances that are stored in the CDS archived heap region. Before this fix, the patching is done incrementally, when a class is resolved. However, when SA tries to do a heap dump, it may see a java.lang.Class instance that is not yet resolved, whose Klass* pointer has not been patched. Dereferencing the unpatched pointer causes SA to fail. (The failure happens on macos only, probably because the invalid dereference causes different exceptions on other platforms due to specific memory layout, and SA is able to handle such exceptions and limp on). The fix is to unconditionally patch all the Klass* pointers during VM initialization. We already patch a lot of stuff at start-up when the CDS archive is relocated, so doing a little patching more doesn't hurt. ---- Passed mach5 tiers 1-4. Ran the failed test manually on macos and it passed. Thanks - Ioi From chris.plummer at oracle.com Tue Apr 14 22:34:45 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 14 Apr 2020 15:34:45 -0700 Subject: RFR[S] 8241158 SA TestHeapDumpForInvokeDynamic.java fails when CDS archive is relocated In-Reply-To: <53af11d5-830d-678c-7eb8-e97875c01770@oracle.com> References: <53af11d5-830d-678c-7eb8-e97875c01770@oracle.com> Message-ID: <86ee56f9-7442-6eb2-2eea-6a93433d44f5@oracle.com> [Not a review] Hi Ioi, Your ProblemList.txt is out of date. All those Solaris entries for 8193639 are now gone. thanks, Chris On 4/14/20 3:01 PM, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8241158 > http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ > > This is a bug in the CDS relocation code. When > -XX:ArchiveRelocationMode=1 is > specified, the CDS archive is mapped to an address picked by the OS > (instead of the default address 0x800000000). As a result, we need to > patch > the native Klass* pointers inside java.lang.Class instances that are > stored in the CDS archived heap region. > > Before this fix, the patching is done incrementally, when a class is > resolved. > However, when SA tries to do a heap dump, it may see a java.lang.Class > instance > that is not yet resolved, whose Klass* pointer has not been patched. > Dereferencing the unpatched pointer causes SA to fail. > > (The failure happens on macos only, probably because the invalid > dereference > causes different exceptions on other platforms due to specific memory > layout, > and SA is able to handle such exceptions and limp on). > > The fix is to unconditionally patch all the Klass* pointers during VM > initialization. > > We already patch a lot of stuff at start-up when the CDS archive is > relocated, > so doing a little patching more doesn't hurt. > > ---- > > Passed mach5 tiers 1-4. Ran the failed test manually on macos and it > passed. > > Thanks > - Ioi From serguei.spitsyn at oracle.com Wed Apr 15 00:34:25 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Apr 2020 17:34:25 -0700 Subject: Ping: Re: RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent In-Reply-To: <531767b2-1f90-dcb1-95a8-8fe5af4483bd@oracle.com> References: <8d884fcb-f424-1b54-7ece-5260037b2843@oracle.com> <01f77be3-e7d2-a051-80ab-e81c83922cf6@oracle.com> <6c008d7c-db6a-e9ad-5b49-e90703e19bad@oracle.com> <531767b2-1f90-dcb1-95a8-8fe5af4483bd@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Apr 15 03:37:28 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 14 Apr 2020 20:37:28 -0700 Subject: Are there limits to SA's ability to produce a stack trace for a thread? Message-ID: <5dc92643-b4ba-61fd-20d0-42ac4c13af5c@oracle.com> An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Wed Apr 15 05:07:17 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 14 Apr 2020 22:07:17 -0700 Subject: RFR[S] 8241158 SA TestHeapDumpForInvokeDynamic.java fails when CDS archive is relocated In-Reply-To: <86ee56f9-7442-6eb2-2eea-6a93433d44f5@oracle.com> References: <53af11d5-830d-678c-7eb8-e97875c01770@oracle.com> <86ee56f9-7442-6eb2-2eea-6a93433d44f5@oracle.com> Message-ID: <706bd1c4-1741-8893-266b-8f135ec2767a@oracle.com> Hi Chris, Thanks for the info. I've synced with the latest repo and updated the webrev in-place: http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ I'll rerun tiers 1-4 as two of the affected tests (ClhsdbDumpheap.java, TestHeapDumpForInvokeDynamic.java) will now be executed on macos by mach5. Thanks - Ioi On 4/14/20 3:34 PM, Chris Plummer wrote: > [Not a review] > > Hi Ioi, > > Your ProblemList.txt is out of date. All those Solaris entries for > 8193639 are now gone. > > thanks, > > Chris > > On 4/14/20 3:01 PM, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8241158 >> http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ >> >> This is a bug in the CDS relocation code. When >> -XX:ArchiveRelocationMode=1 is >> specified, the CDS archive is mapped to an address picked by the OS >> (instead of the default address 0x800000000). As a result, we need to >> patch >> the native Klass* pointers inside java.lang.Class instances that are >> stored in the CDS archived heap region. >> >> Before this fix, the patching is done incrementally, when a class is >> resolved. >> However, when SA tries to do a heap dump, it may see a >> java.lang.Class instance >> that is not yet resolved, whose Klass* pointer has not been patched. >> Dereferencing the unpatched pointer causes SA to fail. >> >> (The failure happens on macos only, probably because the invalid >> dereference >> causes different exceptions on other platforms due to specific memory >> layout, >> and SA is able to handle such exceptions and limp on). >> >> The fix is to unconditionally patch all the Klass* pointers during VM >> initialization. >> >> We already patch a lot of stuff at start-up when the CDS archive is >> relocated, >> so doing a little patching more doesn't hurt. >> >> ---- >> >> Passed mach5 tiers 1-4. Ran the failed test manually on macos and it >> passed. >> >> Thanks >> - Ioi > From david.holmes at oracle.com Wed Apr 15 05:28:40 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Apr 2020 15:28:40 +1000 Subject: RFR (S) 8074292: nsk/jdb/kill/kill001: generateOopMap.cpp assert(bb->is_reachable()) failed In-Reply-To: <1e3d4907-d54a-df0e-e0d3-8bbda8c5394a@oracle.com> References: <6e38070c-f166-a0c2-8b8d-d698e5f5bcf3@oracle.com> <1e3d4907-d54a-df0e-e0d3-8bbda8c5394a@oracle.com> Message-ID: <0a87b7cd-7dfe-0831-05e1-8d48f5eb6755@oracle.com> On 14/04/2020 10:36 pm, coleen.phillimore at oracle.com wrote: > On 4/13/20 10:49 PM, David Holmes wrote: >> Hi Coleen, >> >> On 14/04/2020 12:34 am, coleen.phillimore at oracle.com wrote: >>> Summary: Do not install async exceptions at_safepoint for each bytecode. >> >> I'm still not certain that we have to go this far to solve this >> problem, but it does sound like a relatively simple solution provided >> there are no unintended consequences. >> >>> See CR for a lot more details.? This change calls a new >>> InterpreterRuntime::at_safepoint_async_safe() which installs the >>> async exception in the interpreter at backward branches and returns. >>> This uses safepoint polling code in the interpreter for each >>> platform.? These changes (cross) compile on platforms that Oracle >>> doesn't support but I don't know if they work. >>> >>> I'm not convinced the platform specific changes are necessary, >>> because calls to the runtime from many bytecodes will install the >>> async exception, so it's essentially installed "enough" for this >>> deprecated feature.? I tested the changes with *and* without the >>> platform specific changes with no failure, which included the jdb, >>> jdi and jvmti serviceability tests. >> >> I don't understand what you mean here. If the whole basis of this fix >> is "don't install async exceptions other than at backward branches and >> returns" then how is that implemented without the changes in the >> interpreter code? >> >> If this can be fixed just by adjusting the actual monitor code then I >> would much prefer that. It took me a while to get my head around the >> dispatch changes in interpreter code and even then I don't see how >> those changes only impact backward branches and returns ?? > > You have to read the comments in the bug again.? There *is* special code > to not install the async exception in the monitorexit code. That is not > enough to prevent this bug.? You can also read the old bug report you > linked to this one. I know there is some special handling in monitorexit already, I was referring to additional special handling around the monitorexit to disable whatever piece of code is currently installing the async exception. > The interpreter code dispatch_next passes "true" if it's a backwards > branch, that's how it can tell. Okay - I see dispatch_next is passed generate_poll=true for returns but I can't see where backward branches come into play. Your changes cause the at_safepoint_async_safe to be called in that case, whereas any other code paths that lead to at_safepoint no longer install the async exception. So things are a bit clearer in that regard. > My point was that there are enough code paths that install async > exceptions *other than monitorenter and monitorexit* that maybe it's not > necessary to install them at backwards branches and returns.? I suppose > someone could construct a test case to show otherwise. Yes I understood that was the query, but without knowing exactly where those code paths are it is hard to comment on whether there is adequate coverage. Even with installing on backward branches there is a risk that small loops can be unrolled and so lose the check (indeed that is what "counted loops" in the JIT does) and thus we rely on these other code paths anyway. >>> This change also makes InterpreterRuntime::monitorexit a JRT_LEAF >>> bytecode. The code to check for exceptions is outside the runtime >>> call. I ran the JCK vm and lang tests on this change with no failure. >>> >>> Tested with tier1-6. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8074292.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8074292 >> >> ./cpu/x86/interp_masm_x86.cpp >> >> It took me a long time to figure out how the new logic worked compared >> to the old logic. Even then I'm unclear about the effective recursive >> dispatch path: dispatch_base(generate_poll=true) -> dispatch_via -> >> dispatch_base(generate_poll=false) - does it work okay with >> VerifyActivationFrameSize? It seems a rather convoluted way to >> effectively just execute: >> >> ?858?? lea(rscratch1, ExternalAddress((address)table)); >> ?859?? jmp(Address(rscratch1, rbx, Address::times_8)); > > I could test it with VerifyActivationFrameSize.? Or I could just add the > two instructions per platform.? I mostly copied the code in > generate_safept_entry_for.? It might be better to just copy the > instructions. > >> >> --- >> >> src/hotspot/share/interpreter/interpreterRuntime.cpp >> >> How were you able to drop this code: >> >> 791?? if (elem == NULL || h_obj()->is_unlocked()) { >> 792 THROW(vmSymbols::java_lang_IllegalMonitorStateException()); >> 793?? } >> >> ? >> ?and this: > > The caller throws the exception for these cases. Sorry but I don't see that in the caller e.g. InterpreterMacroAssembler::unlock_object. Further you are not allowing for elem to be NULL which will lead to a crash when you dereference it. >> >> 798 #ifdef ASSERT >> 799 thread->last_frame().interpreter_frame_verify_monitor(elem); >> 800 #endif >> > > This seemed redundant. Possibly, but I assume the pairing in monitorenter and monitorexit around the actual monitor operation is to ensure that the stack frame info is not unexpectedly messed up. Maybe it is redundant to call before and after, but then maybe the same is true in monitorenter. David ----- > Coleen >> ? >> >> Thanks, >> David >> >>> Thanks, >>> Coleen >>> > From david.holmes at oracle.com Wed Apr 15 05:56:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Apr 2020 15:56:29 +1000 Subject: Are there limits to SA's ability to produce a stack trace for a thread? In-Reply-To: <5dc92643-b4ba-61fd-20d0-42ac4c13af5c@oracle.com> References: <5dc92643-b4ba-61fd-20d0-42ac4c13af5c@oracle.com> Message-ID: Hi Chris, On 15/04/2020 1:37 pm, Chris Plummer wrote: > Hello, > > [Sorry this email got kind of long. To cut to the chase, I want to know > if there are times where it is acceptable for SA to not be able to > produce a stack trace for a thread. Details below if you are interested.] How does the SA currently attempt to get a stacktrace for a thread? If the current mechanism has limitations then perhaps that will be addressed now that we have per-thread handshakes? With handshakes the target thread will always be brought to a state where the stack is walkable. That said I thought all existing mechanisms used a safepoint VM op to get a stacktrace for a different thread. Cheers, David ----- > We have a number of SA tests that request a thread dump, look for a > specific symbol in the thread dump, and fail if the symbol is not found. > Normally what they are looking for is LingeredApp.main() which should be > in the stack trace of the main thread. ClhsdbJstack.java is one such > test. It expects the main thread to look like: > > "main" #1 prio=5 tid=0x000001d6301de800 nid=0x3258 waiting on condition > [0x0000007fc1dff000] > ?? java.lang.Thread.State: TIMED_WAITING (sleeping) > ?? JavaThread state: _thread_blocked > ?- java.lang.Thread.sleep(long) @bci=0, pc=0x000001d640d0f417, > Method*=0x00000008000e8898 (Interpreted frame) > ?- jdk.test.lib.apps.LingeredApp.main(java.lang.String[]) @bci=54, > line=499, pc=0x000001d640d0a1b3, Method*=0x000001d658673ba0 (Interpreted > frame) > > But sometimes all it gets is: > > "main" #1 prio=5 tid=0x00007fab2e802000 nid=0x2303 runnable > [0x0000000000000000] > ???java.lang.Thread.State: RUNNABLE > ???JavaThread state: _thread_in_java > > This results in the test failing because it does not find > LingeredApp.main in the output. The state for the passing case is always > _thread_blocked and for the failing case _thread_in_java. This has been > reported by the following CR: > > [1] JDK-8242411 - serviceability/sa/ClhsdbCDSJstackPrintAll.java fails > with Test ERROR java.lang.RuntimeException: 'LingeredApp.main' missing > from stdout/stderr > > After starting, LingeredApp.main sits in a loop: > > ??????????? while (Files.exists(path)) { > ??????????????? // Touch the lock to indicate our readiness > ??????????????? setLastModified(theLockFileName, epoch()); > ??????????????? Thread.sleep(spinDelay); > ??????????? } > > So it's basically waiting for the lock file to be deleted. By default > spinDelay is 1 second. I suspected the issue I was seeing was due to > asking for the thread dump when not blocked on the sleep(), so I changed > spingDelay to 1ms. That made this missing stack trace issue much easier > to reproduce, plus a several other bugs that are filed, but normally > rarely reproduce: > > [2] JDK-8231634 - SA stack walking fails with "illegal bci" > [3] JDK-8240781 - serviceability/sa/ClhsdbJdis.java fails with > "java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for > length 1" > [4] JDK-8211923 - [Testbug] serviceability/sa/ClhsdbFindPC.java > ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 > [5] JDK-8204994 - SA might fail to attach to process with "Windbg Error: > WaitForEvent failed" > > The "illegal bci" failure I haven't looked into much, but is likely an > SA bug due to SA having issues with (and probably making assumptions > about) the state of the stack. > > The two ArrayIndexOutOfBoundsException bugs are dups. They fail because > the stack trace of the main thread is missing, and some String splitting > logic in the test therefore fails and produces the > ArrayIndexOutOfBoundsException. > > I'm not sure about the "WaitForEvent failed". It could be unrelated. > > I can probably make these all go away buy having Lingered.main() spawn a > helper thread to do the above loop in. That would keep the main thread > stable (blocked on a Thread.join). However, it also would hide some > issues(like the "illegal bci" failure). > > The main reason for the email is to ask what are the expectations of > SA's ability to dump a thread's stack trace. Is it expected that > sometimes the thread will be in a state that prevents dumping the stack? > I know for example that the reason we sometimes don't see a stack is > because thread.getLastJavaVFrameDbg() is returning null. Basically SA > throws up its hands and says "I can't do it"? Is that acceptable in some > cases. > > thanks, > > Chris > > [1] https://bugs.openjdk.java.net/browse/JDK-8242411 > [2] https://bugs.openjdk.java.net/browse/JDK-8231634 > [3] https://bugs.openjdk.java.net/browse/JDK-8240781 > [4] https://bugs.openjdk.java.net/browse/JDK-8211923 > [5] https://bugs.openjdk.java.net/browse/JDK-8204994 From chris.plummer at oracle.com Wed Apr 15 06:13:35 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 14 Apr 2020 23:13:35 -0700 Subject: Are there limits to SA's ability to produce a stack trace for a thread? In-Reply-To: References: <5dc92643-b4ba-61fd-20d0-42ac4c13af5c@oracle.com> Message-ID: <674c0f5e-3c99-c215-a9ef-357786468d28@oracle.com> On 4/14/20 10:56 PM, David Holmes wrote: > Hi Chris, > > On 15/04/2020 1:37 pm, Chris Plummer wrote: >> Hello, >> >> [Sorry this email got kind of long. To cut to the chase, I want to >> know if there are times where it is acceptable for SA to not be able >> to produce a stack trace for a thread. Details below if you are >> interested.] > > How does the SA currently attempt to get a stacktrace for a thread? If > the current mechanism has limitations then perhaps that will be > addressed now that we have per-thread handshakes? With handshakes the > target thread will always be brought to a state where the stack is > walkable. That said I thought all existing mechanisms used a safepoint > VM op to get a stacktrace for a different thread. Hi David, I don't know the details, but I think there is no safepointing involved. Consider that you can also get thread stack traces from a JVM core file, which could be produced at any given moment in the JVM's execution. Note SA has lots of safeguards around this. It has ways of verifying if something points to what it is really suppose to point to. For example if SA thinks something is a pointer to a heap object, it verifies that the object header contains a pointer to something that is known to be an Klass, which it can determine by looking at the vtable (and then cross referencing with symbolic info it pulls from the executable). I'm just not too sure to what extent this applies to thread stack walking. As I mentioned below, thread.getLastJavaVFrameDbg() sometimes returns null, thus no stack trace. ? /** This should only be used by a debugger. Uses the current frame ????? guess to attempt to get the topmost JavaVFrame. ????? (getLastJavaVFrame, as a port of the VM's routine, assumes the ????? VM is at a safepoint.) */ ? public JavaVFrame getLastJavaVFrameDbg() { So it seems that since we are not at a safepoint, and there's a lot of "guessing" in the implementation. I gather from this the thread won't always be in a state where we can determine the last vframe, and therefore not in a state where SA can produce a stack trace. thanks, Chris > > Cheers, > David > ----- > > >> We have a number of SA tests that request a thread dump, look for a >> specific symbol in the thread dump, and fail if the symbol is not >> found. Normally what they are looking for is LingeredApp.main() which >> should be in the stack trace of the main thread. ClhsdbJstack.java is >> one such test. It expects the main thread to look like: >> >> "main" #1 prio=5 tid=0x000001d6301de800 nid=0x3258 waiting on >> condition [0x0000007fc1dff000] >> ??? java.lang.Thread.State: TIMED_WAITING (sleeping) >> ??? JavaThread state: _thread_blocked >> ??- java.lang.Thread.sleep(long) @bci=0, pc=0x000001d640d0f417, >> Method*=0x00000008000e8898 (Interpreted frame) >> ??- jdk.test.lib.apps.LingeredApp.main(java.lang.String[]) @bci=54, >> line=499, pc=0x000001d640d0a1b3, Method*=0x000001d658673ba0 >> (Interpreted frame) >> >> But sometimes all it gets is: >> >> "main" #1 prio=5 tid=0x00007fab2e802000 nid=0x2303 runnable >> [0x0000000000000000] >> ????java.lang.Thread.State: RUNNABLE >> ????JavaThread state: _thread_in_java >> >> This results in the test failing because it does not find >> LingeredApp.main in the output. The state for the passing case is >> always _thread_blocked and for the failing case _thread_in_java. This >> has been reported by the following CR: >> >> [1] JDK-8242411 - serviceability/sa/ClhsdbCDSJstackPrintAll.java >> fails with Test ERROR java.lang.RuntimeException: 'LingeredApp.main' >> missing from stdout/stderr >> >> After starting, LingeredApp.main sits in a loop: >> >> ???????????? while (Files.exists(path)) { >> ???????????????? // Touch the lock to indicate our readiness >> ???????????????? setLastModified(theLockFileName, epoch()); >> ???????????????? Thread.sleep(spinDelay); >> ???????????? } >> >> So it's basically waiting for the lock file to be deleted. By default >> spinDelay is 1 second. I suspected the issue I was seeing was due to >> asking for the thread dump when not blocked on the sleep(), so I >> changed spingDelay to 1ms. That made this missing stack trace issue >> much easier to reproduce, plus a several other bugs that are filed, >> but normally rarely reproduce: >> >> [2] JDK-8231634 - SA stack walking fails with "illegal bci" >> [3] JDK-8240781 - serviceability/sa/ClhsdbJdis.java fails with >> "java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for >> length 1" >> [4] JDK-8211923 - [Testbug] serviceability/sa/ClhsdbFindPC.java >> ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 >> [5] JDK-8204994 - SA might fail to attach to process with "Windbg >> Error: WaitForEvent failed" >> >> The "illegal bci" failure I haven't looked into much, but is likely >> an SA bug due to SA having issues with (and probably making >> assumptions about) the state of the stack. >> >> The two ArrayIndexOutOfBoundsException bugs are dups. They fail >> because the stack trace of the main thread is missing, and some >> String splitting logic in the test therefore fails and produces the >> ArrayIndexOutOfBoundsException. >> >> I'm not sure about the "WaitForEvent failed". It could be unrelated. >> >> I can probably make these all go away buy having Lingered.main() >> spawn a helper thread to do the above loop in. That would keep the >> main thread stable (blocked on a Thread.join). However, it also would >> hide some issues(like the "illegal bci" failure). >> >> The main reason for the email is to ask what are the expectations of >> SA's ability to dump a thread's stack trace. Is it expected that >> sometimes the thread will be in a state that prevents dumping the >> stack? I know for example that the reason we sometimes don't see a >> stack is because thread.getLastJavaVFrameDbg() is returning null. >> Basically SA throws up its hands and says "I can't do it"? Is that >> acceptable in some cases. >> >> thanks, >> >> Chris >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8242411 >> [2] https://bugs.openjdk.java.net/browse/JDK-8231634 >> [3] https://bugs.openjdk.java.net/browse/JDK-8240781 >> [4] https://bugs.openjdk.java.net/browse/JDK-8211923 >> [5] https://bugs.openjdk.java.net/browse/JDK-8204994 From magnus.ihse.bursie at oracle.com Wed Apr 15 07:01:56 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 15 Apr 2020 09:01:56 +0200 Subject: Ping: Re: RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent In-Reply-To: <531767b2-1f90-dcb1-95a8-8fe5af4483bd@oracle.com> References: <8d884fcb-f424-1b54-7ece-5260037b2843@oracle.com> <01f77be3-e7d2-a051-80ab-e81c83922cf6@oracle.com> <6c008d7c-db6a-e9ad-5b49-e90703e19bad@oracle.com> <531767b2-1f90-dcb1-95a8-8fe5af4483bd@oracle.com> Message-ID: <2f711e15-e310-39d5-c4ba-6ebf8f55245a@oracle.com> On 2020-04-14 23:23, Chris Plummer wrote: > Hi Magnus, > > The changes look good. Just one minor issue: > > http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.02/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Metadata.java.frames.html > > Copyright was updated, but no other changes in this file. Thanks for noticing! I reverted that change before pushing. > > BTW, do you know why there were cases in the old code of having the > right generic type in a comment. For example: > > 1177???? private static List/**/ > getInstanceFields(InstanceKlass ik) { > > and > > 1276???? private Map classDataCache = new HashMap(); // > > > It's almost as if some of the code was initially properly written for > generics, but then backported to work with a pre-generics version of jdk. Yeah, isn't it? I have no clue, though. Most of the code is written completely oblivious to generics. Some parts have the typical pre-generics style of documenting in comments what types were expected, but most said nothing about the issue. And a few places has something that look like proper generics commented out. Maybe that's just the original programmer using C++ generics-inspired syntax as a way to comment the expected types? /Magnus > > thanks, > > Chris > > On 4/14/20 2:24 AM, Magnus Ihse Bursie wrote: >> Hi, >> >> Can I please get a review for this, simplified version of the patch? >> This only contain trivial changes, like this: >> - private List objects; // ArrayList >> + private List objects; >> Basically all changes are to the container types List or Map (and a >> few changes from Class to Class). >> >> If the list of all the files look horrible in the webrev, have a look >> at the patch file instead, it is easier to scroll through and check >> the changes: >> http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.02/open.patch >> >> /Magnus >> >> On 2020-03-30 16:25, Magnus Ihse Bursie wrote: >>> >>> >>> On 2020-03-25 20:52, Chris Plummer wrote: >>>> Hi Magus, >>>> >>>> I haven't looked at the changes yet, other to see that there are >>>> many files touched, but after reading below (and only partly >>>> understanding since I don't know this area well), I was wondering >>>> if this issue wouldn't be better served with multiple passes made >>>> to fix the warnings. Start with a straight forward one where you >>>> are maybe only making one or two types of changes, but that affect >>>> a large number of files and don't cascade into other more >>>> complicated changes. This will get a lot of the noise out of the >>>> way, and then we can focus on some of the harder issues you bring >>>> up below. >>> Ok, I did just this. Here is an updated webrev. It contain the bulk >>> of the changes, but all changes are -- I dare not say trivially >>> obvious, but at least no-brainers. Hopefully it should be easier to >>> review so I can get this pushed and out of the way. >>> >>> This also means that it is not possible to turn on the warning just >>> yet. >>> >>> http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.02 >>> >>> >>> /Magnus >>>> >>>> As for testing, I think the following list will capture all of >>>> them, but can't say for sure: >>>> >>>> open/test/hotspot/jtreg/serviceability/sa >>>> open/test/hotspot/jtreg/resourcehogs/serviceability/sa >>>> open/test/jdk/sun/tools/jhsdb >>>> open/test/jdk/sun/tools/jstack >>>> open/test/jdk/sun/tools/jmap >>>> open/test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >>>> >>>> open/test/hotspot/jtreg/compiler/ciReplay/TestSAClient.java >>>> open/test/hotspot/jtreg/compiler/ciReplay/TestSAServer.java >>>> >>>> Chris >>>> >>>> On 3/25/20 12:29 PM, Magnus Ihse Bursie wrote: >>>>> With the recent fixes in JDK-8241310, JDK-8237746 and JDK-8241073, >>>>> and the upcoming fixes to remove the deprecated nashorn and >>>>> jdk.rmi, the JDK build is very close to producing no warnings when >>>>> compiling the Java classes. >>>>> >>>>> The one remaining sinner is jdk.hotspot.agent. Most of the >>>>> warnings here are turned off, but unchecked and deprecation cannot >>>>> be completely silenced. >>>>> >>>>> Since the poor agent does not seem to receive much love nowadays, >>>>> I took it upon myself to fix these warnings, so we can finally get >>>>> a quiet build. >>>>> >>>>> I started to address the unchecked warnings. Unfortunately, this >>>>> was a much bigger task than I anticipated. I had to generify most >>>>> of the module. On the plus side, the code is so much better now. >>>>> And most of the changes were trivial, just tedious. >>>>> >>>>> There are a few places were I'm not entirely happy with the >>>>> current solution, and that at least merits some discussion. >>>>> >>>>> I have resorted to @SuppressWarnings in four classes: >>>>> ciMethodData, MethodData, TableModelComparator and >>>>> VirtualBaseConstructor. All of them has in common that they are >>>>> doing slightly fishy things with classes in collections. I'm not >>>>> entirely sure they are bug-free, but this patch leaves the >>>>> behavior untouched. I did some efforts to sort out the logic, but >>>>> it turned out to be too hairy for me to fix, and it will probably >>>>> require more substantial changes to the workings of the code. >>>>> >>>>> To make the code valid, I have moved ConstMethod to extend >>>>> Metadata instead of VMObject. My understanding is that this is >>>>> benign (and likely intended), but I really need for someone who >>>>> knows the code to confirm this. I have also added a FIXME to >>>>> signal this. I'll remove the FIXME as soon as I get confirmation >>>>> that this is OK. >>>>> (The reason for this is the following piece of code from >>>>> Metadata.java: metadataConstructor.addMapping("ConstMethod", >>>>> ConstMethod.class)) >>>>> >>>>> In ObjectListPanel, there is some code that screams "dead" with >>>>> this change. I added a FIXME to point this out: >>>>> ??? for (Iterator iter = elements.iterator(); iter.hasNext(); >>>>> ) { >>>>> ????? if (iter.next() instanceof Array) { >>>>> ??????? // FIXME: Does not seem possible to happen >>>>> ??????? hasArrays = true; >>>>> ??????? return; >>>>> ????? } >>>>> It seems that if you start pulling this thread, even more dead >>>>> code will unravel, so I'm not so eager to touch this in the >>>>> current patch. But I can remove the FIXME if you want. >>>>> >>>>> My first iteration of this patch tried to generify the >>>>> IntervalTree and related class hierarchy. However, this turned out >>>>> to be impossible due to some weird usage in AnnotatedMemoryPanel, >>>>> where there seemed to be confusion as to whether the tree stored >>>>> Annotations or Addresses. I'm not entirely convinced the code is >>>>> correct, it certainly looked and smelled very fishy. However, I >>>>> reverted these changes since I could not get them to work due to >>>>> this, and it was not needed for the goal of just getting rid of >>>>> the warning. >>>>> >>>>> Finally, I have done no testing apart from verifying that it >>>>> builds. Please advice on suitable tests to run. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241618 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.01 >>>>> >>>>> /Magnus >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Wed Apr 15 07:02:27 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 15 Apr 2020 09:02:27 +0200 Subject: Ping: Re: RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent In-Reply-To: References: <8d884fcb-f424-1b54-7ece-5260037b2843@oracle.com> <01f77be3-e7d2-a051-80ab-e81c83922cf6@oracle.com> <6c008d7c-db6a-e9ad-5b49-e90703e19bad@oracle.com> <531767b2-1f90-dcb1-95a8-8fe5af4483bd@oracle.com> Message-ID: <5ed8d0d1-c002-4d62-3bbb-881bfa27e1b1@oracle.com> On 2020-04-15 02:34, serguei.spitsyn at oracle.com wrote: > Hi Magnus, > > It looks good to me. Thanks for the review, Serguei! /Magnus > > Thanks, > Serguei > > > On 4/14/20 14:23, Chris Plummer wrote: >> Hi Magnus, >> >> The changes look good. Just one minor issue: >> >> http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.02/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Metadata.java.frames.html >> >> Copyright was updated, but no other changes in this file. >> >> BTW, do you know why there were cases in the old code of having the >> right generic type in a comment. For example: >> >> 1177???? private static List/**/ >> getInstanceFields(InstanceKlass ik) { >> >> and >> >> 1276???? private Map classDataCache = new HashMap(); // >> >> >> It's almost as if some of the code was initially properly written for >> generics, but then backported to work with a pre-generics version of jdk. >> >> thanks, >> >> Chris >> >> On 4/14/20 2:24 AM, Magnus Ihse Bursie wrote: >>> Hi, >>> >>> Can I please get a review for this, simplified version of the patch? >>> This only contain trivial changes, like this: >>> - private List objects; // ArrayList >>> + private List objects; >>> Basically all changes are to the container types List or Map (and a >>> few changes from Class to Class). >>> >>> If the list of all the files look horrible in the webrev, have a >>> look at the patch file instead, it is easier to scroll through and >>> check the changes: >>> http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.02/open.patch >>> >>> /Magnus >>> >>> On 2020-03-30 16:25, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2020-03-25 20:52, Chris Plummer wrote: >>>>> Hi Magus, >>>>> >>>>> I haven't looked at the changes yet, other to see that there are >>>>> many files touched, but after reading below (and only partly >>>>> understanding since I don't know this area well), I was wondering >>>>> if this issue wouldn't be better served with multiple passes made >>>>> to fix the warnings. Start with a straight forward one where you >>>>> are maybe only making one or two types of changes, but that affect >>>>> a large number of files and don't cascade into other more >>>>> complicated changes. This will get a lot of the noise out of the >>>>> way, and then we can focus on some of the harder issues you bring >>>>> up below. >>>> Ok, I did just this. Here is an updated webrev. It contain the bulk >>>> of the changes, but all changes are -- I dare not say trivially >>>> obvious, but at least no-brainers. Hopefully it should be easier to >>>> review so I can get this pushed and out of the way. >>>> >>>> This also means that it is not possible to turn on the warning just >>>> yet. >>>> >>>> http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.02 >>>> >>>> >>>> /Magnus >>>>> >>>>> As for testing, I think the following list will capture all of >>>>> them, but can't say for sure: >>>>> >>>>> open/test/hotspot/jtreg/serviceability/sa >>>>> open/test/hotspot/jtreg/resourcehogs/serviceability/sa >>>>> open/test/jdk/sun/tools/jhsdb >>>>> open/test/jdk/sun/tools/jstack >>>>> open/test/jdk/sun/tools/jmap >>>>> open/test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >>>>> >>>>> open/test/hotspot/jtreg/compiler/ciReplay/TestSAClient.java >>>>> open/test/hotspot/jtreg/compiler/ciReplay/TestSAServer.java >>>>> >>>>> Chris >>>>> >>>>> On 3/25/20 12:29 PM, Magnus Ihse Bursie wrote: >>>>>> With the recent fixes in JDK-8241310, JDK-8237746 and >>>>>> JDK-8241073, and the upcoming fixes to remove the deprecated >>>>>> nashorn and jdk.rmi, the JDK build is very close to producing no >>>>>> warnings when compiling the Java classes. >>>>>> >>>>>> The one remaining sinner is jdk.hotspot.agent. Most of the >>>>>> warnings here are turned off, but unchecked and deprecation >>>>>> cannot be completely silenced. >>>>>> >>>>>> Since the poor agent does not seem to receive much love nowadays, >>>>>> I took it upon myself to fix these warnings, so we can finally >>>>>> get a quiet build. >>>>>> >>>>>> I started to address the unchecked warnings. Unfortunately, this >>>>>> was a much bigger task than I anticipated. I had to generify most >>>>>> of the module. On the plus side, the code is so much better now. >>>>>> And most of the changes were trivial, just tedious. >>>>>> >>>>>> There are a few places were I'm not entirely happy with the >>>>>> current solution, and that at least merits some discussion. >>>>>> >>>>>> I have resorted to @SuppressWarnings in four classes: >>>>>> ciMethodData, MethodData, TableModelComparator and >>>>>> VirtualBaseConstructor. All of them has in common that they are >>>>>> doing slightly fishy things with classes in collections. I'm not >>>>>> entirely sure they are bug-free, but this patch leaves the >>>>>> behavior untouched. I did some efforts to sort out the logic, but >>>>>> it turned out to be too hairy for me to fix, and it will probably >>>>>> require more substantial changes to the workings of the code. >>>>>> >>>>>> To make the code valid, I have moved ConstMethod to extend >>>>>> Metadata instead of VMObject. My understanding is that this is >>>>>> benign (and likely intended), but I really need for someone who >>>>>> knows the code to confirm this. I have also added a FIXME to >>>>>> signal this. I'll remove the FIXME as soon as I get confirmation >>>>>> that this is OK. >>>>>> (The reason for this is the following piece of code from >>>>>> Metadata.java: metadataConstructor.addMapping("ConstMethod", >>>>>> ConstMethod.class)) >>>>>> >>>>>> In ObjectListPanel, there is some code that screams "dead" with >>>>>> this change. I added a FIXME to point this out: >>>>>> ??? for (Iterator iter = elements.iterator(); >>>>>> iter.hasNext(); ) { >>>>>> ????? if (iter.next() instanceof Array) { >>>>>> ??????? // FIXME: Does not seem possible to happen >>>>>> ??????? hasArrays = true; >>>>>> ??????? return; >>>>>> ????? } >>>>>> It seems that if you start pulling this thread, even more dead >>>>>> code will unravel, so I'm not so eager to touch this in the >>>>>> current patch. But I can remove the FIXME if you want. >>>>>> >>>>>> My first iteration of this patch tried to generify the >>>>>> IntervalTree and related class hierarchy. However, this turned >>>>>> out to be impossible due to some weird usage in >>>>>> AnnotatedMemoryPanel, where there seemed to be confusion as to >>>>>> whether the tree stored Annotations or Addresses. I'm not >>>>>> entirely convinced the code is correct, it certainly looked and >>>>>> smelled very fishy. However, I reverted these changes since I >>>>>> could not get them to work due to this, and it was not needed for >>>>>> the goal of just getting rid of the warning. >>>>>> >>>>>> Finally, I have done no testing apart from verifying that it >>>>>> builds. Please advice on suitable tests to run. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8241618 >>>>>> WebRev: >>>>>> http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.01 >>>>>> >>>>>> /Magnus >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Apr 15 07:16:58 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Apr 2020 00:16:58 -0700 Subject: Ping: Re: RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent In-Reply-To: <5ed8d0d1-c002-4d62-3bbb-881bfa27e1b1@oracle.com> References: <8d884fcb-f424-1b54-7ece-5260037b2843@oracle.com> <01f77be3-e7d2-a051-80ab-e81c83922cf6@oracle.com> <6c008d7c-db6a-e9ad-5b49-e90703e19bad@oracle.com> <531767b2-1f90-dcb1-95a8-8fe5af4483bd@oracle.com> <5ed8d0d1-c002-4d62-3bbb-881bfa27e1b1@oracle.com> Message-ID: <4c011dbf-faaf-0da6-9055-edf23c2006e9@oracle.com> An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Wed Apr 15 08:18:03 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 15 Apr 2020 10:18:03 +0200 Subject: RFR: JDK-8242804 Fix trivial deprecation issues in jdk.hotspot.agent Message-ID: <9d8111bf-a286-d963-dc6d-3f80c7fcd4ae@oracle.com> In the quest for getting rid of warning messages in jdk.hotspot.agent, the time has now come for another major source of deprecation messages, that are trivial to fix and might hide more tricky issues. This patch handles the "new Integer(42)" pattern of explicit boxing, which is deprecated. I have fixed this using the improved autoboxing functionality in modern Java (e.g. just "42"), wherever possible (which was most places). For some cases, a modern factory method was preferable. This patch also fixes newInstance() deprecation. As with the previous patches, it might be easier to just read the patch file, http://cr.openjdk.java.net/~ihse/JDK-8242804-SA-boxing-deprecations/webrev.01/open.patch. (Fortunately, there are a log less changes in this patch than the previous ones.) Bug: https://bugs.openjdk.java.net/browse/JDK-8242804 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8242804-SA-boxing-deprecations/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Apr 15 09:13:32 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 15 Apr 2020 11:13:32 +0200 Subject: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent Message-ID: After JDK-8242804, a few places remain which are using deprecated methods. They too should be fixed, and the deprecation warning should no longer be disabled. This patch presupposes the fix for JDK-8242804 has been applied (otherwise we cannot turn the deprecation warning back on). Some brief comments about each fix: * In ConstantPool.java, there was a boxing deprecation that I missed in JDK-8242804 (sorry!) * In HighPrecisionJScrollBar.java, there is a trivial replacement to use BigDecimal.divide with RoundingMode semantics. * In SourceCodePanel.java, I settled for suppressing the warning. The issue here is that modelToView (which returns a Rectangle) is deprecated in favor of modelToView2D, which returns a Rectangle2D (which is a supertype of Rectangle). But we use the result in scrollRectToVisible, and there exist no version of that which accepts a Rectangle2D instead of a Rectangle, nor a way to created a Rectangle from a Rectangle2D (that I could find). In practice, this is just a game of types -- under the hood, modelToView2D still returns a Rectangle (even though it only promises a Rectangle2D). The alternative here would be to cast the result of modelToView2D to a Rectangle, but I found that less attractive. * In JTreeTable.java, I've replaced the use of the old-style modifier mask with the new-style extended modifier mask. To the best of my understanding, this will just work the same for the code here (and for the MouseEvent constructor, using the extended mask is actually prescribed). Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 From david.holmes at oracle.com Wed Apr 15 09:22:20 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Apr 2020 19:22:20 +1000 Subject: RFR: JDK-8242804 Fix trivial deprecation issues in jdk.hotspot.agent In-Reply-To: <9d8111bf-a286-d963-dc6d-3f80c7fcd4ae@oracle.com> References: <9d8111bf-a286-d963-dc6d-3f80c7fcd4ae@oracle.com> Message-ID: <0a11939a-41ae-58ff-4096-4585abfd95a4@oracle.com> Hi Magnus, This all looks good to me. Thanks, David On 15/04/2020 6:18 pm, Magnus Ihse Bursie wrote: > In the quest for getting rid of warning messages in jdk.hotspot.agent, > the time has now come for another major source of deprecation messages, > that are trivial to fix and might hide more tricky issues. > > This patch handles the "new Integer(42)" pattern of explicit boxing, > which is deprecated. I have fixed this using the improved autoboxing > functionality in modern Java (e.g. just "42"), wherever possible (which > was most places). For some cases, a modern factory method was preferable. > > This patch also fixes newInstance() deprecation. > > As with the previous patches, it might be easier to just read the patch > file, > http://cr.openjdk.java.net/~ihse/JDK-8242804-SA-boxing-deprecations/webrev.01/open.patch. > (Fortunately, there are a log less changes in this patch than the > previous ones.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242804 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8242804-SA-boxing-deprecations/webrev.01 > > > /Magnus From david.holmes at oracle.com Wed Apr 15 09:37:22 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Apr 2020 19:37:22 +1000 Subject: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent In-Reply-To: References: Message-ID: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com> Hi Magnus, This one sounds like it needs a Swing/Java2D developer to review it :) Cheers, David On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: > After JDK-8242804, a few places remain which are using deprecated > methods. They too should be fixed, and the deprecation warning should no > longer be disabled. > > This patch presupposes the fix for JDK-8242804 has been applied > (otherwise we cannot turn the deprecation warning back on). > > Some brief comments about each fix: > > * In ConstantPool.java, there was a boxing deprecation that I missed in > JDK-8242804 (sorry!) > > * In HighPrecisionJScrollBar.java, there is a trivial replacement to use > BigDecimal.divide with RoundingMode semantics. > > * In SourceCodePanel.java, I settled for suppressing the warning. The > issue here is that modelToView (which returns a Rectangle) is deprecated > in favor of modelToView2D, which returns a Rectangle2D (which is a > supertype of Rectangle). But we use the result in scrollRectToVisible, > and there exist no version of that which accepts a Rectangle2D instead > of a Rectangle, nor a way to created a Rectangle from a Rectangle2D > (that I could find). In practice, this is just a game of types -- under > the hood, modelToView2D still returns a Rectangle (even though it only > promises a Rectangle2D). The alternative here would be to cast the > result of modelToView2D to a Rectangle, but I found that less attractive. > > * In JTreeTable.java, I've replaced the use of the old-style modifier > mask with the new-style extended modifier mask. To the best of my > understanding, this will just work the same for the code here (and for > the MouseEvent constructor, using the extended mask is actually > prescribed). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 > > From magnus.ihse.bursie at oracle.com Wed Apr 15 10:05:22 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 15 Apr 2020 12:05:22 +0200 Subject: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent In-Reply-To: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com> References: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com> Message-ID: Hi swing-dev, Do you have any other suggestions for how to resolve the deprecation of modelToView() in this code? Basically, the code does this: ?????? Rectangle rect = source.modelToView(offset); ?????? source.scrollRectToVisible(rect); but scrollRectToVisible() requires a Rectangle (a subtype of Rectangle2D), and modelToView() is deprecated with reference to modelToView2D(), which returns a Rectangle2D, which is thus unusable by scrollRectToVisible(). I also cannot find a way to create a new Rectangle, given a Rectangle2D. In practice, under the hood, it's still just Rectangles (not Rectangle2D). /Magnus On 2020-04-15 11:37, David Holmes wrote: > Hi Magnus, > > This one sounds like it needs a Swing/Java2D developer to review it :) > > Cheers, > David > > On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: >> After JDK-8242804, a few places remain which are using deprecated >> methods. They too should be fixed, and the deprecation warning should >> no longer be disabled. >> >> This patch presupposes the fix for JDK-8242804 has been applied >> (otherwise we cannot turn the deprecation warning back on). >> >> Some brief comments about each fix: >> >> * In ConstantPool.java, there was a boxing deprecation that I missed >> in JDK-8242804 (sorry!) >> >> * In HighPrecisionJScrollBar.java, there is a trivial replacement to >> use BigDecimal.divide with RoundingMode semantics. >> >> * In SourceCodePanel.java, I settled for suppressing the warning. The >> issue here is that modelToView (which returns a Rectangle) is >> deprecated in favor of modelToView2D, which returns a Rectangle2D >> (which is a supertype of Rectangle). But we use the result in >> scrollRectToVisible, and there exist no version of that which accepts >> a Rectangle2D instead of a Rectangle, nor a way to created a >> Rectangle from a Rectangle2D (that I could find). In practice, this >> is just a game of types -- under the hood, modelToView2D still >> returns a Rectangle (even though it only promises a Rectangle2D). The >> alternative here would be to cast the result of modelToView2D to a >> Rectangle, but I found that less attractive. >> >> * In JTreeTable.java, I've replaced the use of the old-style modifier >> mask with the new-style extended modifier mask. To the best of my >> understanding, this will just work the same for the code here (and >> for the MouseEvent constructor, using the extended mask is actually >> prescribed). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 >> >> From prasanta.sadhukhan at oracle.com Wed Apr 15 10:59:35 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 15 Apr 2020 16:29:35 +0530 Subject: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent In-Reply-To: References: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com> Message-ID: Hi Magnus, Why can't we just use modelToView2D() to get Rectangle2D and then cast to Rectangle tobe used in scrollRectToVisible() or else use (int)Rectangle2D.getX(), (int)getY(), getWidth(), getHeight() to construct a new Rectangle()? Regard Prasanta On 15-Apr-20 3:35 PM, Magnus Ihse Bursie wrote: > Hi swing-dev, > > Do you have any other suggestions for how to resolve the deprecation > of modelToView() in this code? > > Basically, the code does this: > > ?????? Rectangle rect = source.modelToView(offset); > ?????? source.scrollRectToVisible(rect); > > but scrollRectToVisible() requires a Rectangle (a subtype of > Rectangle2D), and modelToView() is deprecated with reference to > modelToView2D(), which returns a Rectangle2D, which is thus unusable > by scrollRectToVisible(). I also cannot find a way to create a new > Rectangle, given a Rectangle2D. > > In practice, under the hood, it's still just Rectangles (not > Rectangle2D). > > /Magnus > > On 2020-04-15 11:37, David Holmes wrote: >> Hi Magnus, >> >> This one sounds like it needs a Swing/Java2D developer to review it :) >> >> Cheers, >> David >> >> On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: >>> After JDK-8242804, a few places remain which are using deprecated >>> methods. They too should be fixed, and the deprecation warning >>> should no longer be disabled. >>> >>> This patch presupposes the fix for JDK-8242804 has been applied >>> (otherwise we cannot turn the deprecation warning back on). >>> >>> Some brief comments about each fix: >>> >>> * In ConstantPool.java, there was a boxing deprecation that I missed >>> in JDK-8242804 (sorry!) >>> >>> * In HighPrecisionJScrollBar.java, there is a trivial replacement to >>> use BigDecimal.divide with RoundingMode semantics. >>> >>> * In SourceCodePanel.java, I settled for suppressing the warning. >>> The issue here is that modelToView (which returns a Rectangle) is >>> deprecated in favor of modelToView2D, which returns a Rectangle2D >>> (which is a supertype of Rectangle). But we use the result in >>> scrollRectToVisible, and there exist no version of that which >>> accepts a Rectangle2D instead of a Rectangle, nor a way to created a >>> Rectangle from a Rectangle2D (that I could find). In practice, this >>> is just a game of types -- under the hood, modelToView2D still >>> returns a Rectangle (even though it only promises a Rectangle2D). >>> The alternative here would be to cast the result of modelToView2D to >>> a Rectangle, but I found that less attractive. >>> >>> * In JTreeTable.java, I've replaced the use of the old-style >>> modifier mask with the new-style extended modifier mask. To the best >>> of my understanding, this will just work the same for the code here >>> (and for the MouseEvent constructor, using the extended mask is >>> actually prescribed). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 >>> >>> > From magnus.ihse.bursie at oracle.com Wed Apr 15 12:30:00 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 15 Apr 2020 14:30:00 +0200 Subject: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent In-Reply-To: References: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com> Message-ID: <194c6cca-f6c5-5250-3dbf-5c03036c3280@oracle.com> On 2020-04-15 12:59, Prasanta Sadhukhan wrote: > Hi Magnus, > > Why can't we just use modelToView2D() to get Rectangle2D and then cast > to Rectangle tobe used in scrollRectToVisible() or else use > (int)Rectangle2D.getX(), (int)getY(), getWidth(), getHeight() to > construct a new Rectangle()? Casting a Rectangle2D to a Rectangle does not seem to me to be an improvement. That presupposes even more knowledge about implementation details. However, I'll look into constructing a Rectangle using the getters from the Rectangle2D, as you suggested. Thanks! /Magnus > > Regard > Prasanta > On 15-Apr-20 3:35 PM, Magnus Ihse Bursie wrote: >> Hi swing-dev, >> >> Do you have any other suggestions for how to resolve the deprecation >> of modelToView() in this code? >> >> Basically, the code does this: >> >> ?????? Rectangle rect = source.modelToView(offset); >> ?????? source.scrollRectToVisible(rect); >> >> but scrollRectToVisible() requires a Rectangle (a subtype of >> Rectangle2D), and modelToView() is deprecated with reference to >> modelToView2D(), which returns a Rectangle2D, which is thus unusable >> by scrollRectToVisible(). I also cannot find a way to create a new >> Rectangle, given a Rectangle2D. >> >> In practice, under the hood, it's still just Rectangles (not >> Rectangle2D). >> >> /Magnus >> >> On 2020-04-15 11:37, David Holmes wrote: >>> Hi Magnus, >>> >>> This one sounds like it needs a Swing/Java2D developer to review it :) >>> >>> Cheers, >>> David >>> >>> On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: >>>> After JDK-8242804, a few places remain which are using deprecated >>>> methods. They too should be fixed, and the deprecation warning >>>> should no longer be disabled. >>>> >>>> This patch presupposes the fix for JDK-8242804 has been applied >>>> (otherwise we cannot turn the deprecation warning back on). >>>> >>>> Some brief comments about each fix: >>>> >>>> * In ConstantPool.java, there was a boxing deprecation that I >>>> missed in JDK-8242804 (sorry!) >>>> >>>> * In HighPrecisionJScrollBar.java, there is a trivial replacement >>>> to use BigDecimal.divide with RoundingMode semantics. >>>> >>>> * In SourceCodePanel.java, I settled for suppressing the warning. >>>> The issue here is that modelToView (which returns a Rectangle) is >>>> deprecated in favor of modelToView2D, which returns a Rectangle2D >>>> (which is a supertype of Rectangle). But we use the result in >>>> scrollRectToVisible, and there exist no version of that which >>>> accepts a Rectangle2D instead of a Rectangle, nor a way to created >>>> a Rectangle from a Rectangle2D (that I could find). In practice, >>>> this is just a game of types -- under the hood, modelToView2D still >>>> returns a Rectangle (even though it only promises a Rectangle2D). >>>> The alternative here would be to cast the result of modelToView2D >>>> to a Rectangle, but I found that less attractive. >>>> >>>> * In JTreeTable.java, I've replaced the use of the old-style >>>> modifier mask with the new-style extended modifier mask. To the >>>> best of my understanding, this will just work the same for the code >>>> here (and for the MouseEvent constructor, using the extended mask >>>> is actually prescribed). >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 >>>> >>>> >> From magnus.ihse.bursie at oracle.com Wed Apr 15 13:00:27 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 15 Apr 2020 15:00:27 +0200 Subject: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent In-Reply-To: <194c6cca-f6c5-5250-3dbf-5c03036c3280@oracle.com> References: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com> <194c6cca-f6c5-5250-3dbf-5c03036c3280@oracle.com> Message-ID: <7e66a73d-910c-52f7-683b-f6964c4942b2@oracle.com> Here is an updated version, that avoids the SuppressWarnings for modelToView: http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.02 (Only change is in SourceCodePanel.java compared to v01) /Magnus On 2020-04-15 14:30, Magnus Ihse Bursie wrote: > > > On 2020-04-15 12:59, Prasanta Sadhukhan wrote: >> Hi Magnus, >> >> Why can't we just use modelToView2D() to get Rectangle2D and then >> cast to Rectangle tobe used in scrollRectToVisible() or else use >> (int)Rectangle2D.getX(), (int)getY(), getWidth(), getHeight() to >> construct a new Rectangle()? > Casting a Rectangle2D to a Rectangle does not seem to me to be an > improvement. That presupposes even more knowledge about implementation > details. > > However, I'll look into constructing a Rectangle using the getters > from the Rectangle2D, as you suggested. Thanks! > > /Magnus >> >> Regard >> Prasanta >> On 15-Apr-20 3:35 PM, Magnus Ihse Bursie wrote: >>> Hi swing-dev, >>> >>> Do you have any other suggestions for how to resolve the deprecation >>> of modelToView() in this code? >>> >>> Basically, the code does this: >>> >>> ?????? Rectangle rect = source.modelToView(offset); >>> ?????? source.scrollRectToVisible(rect); >>> >>> but scrollRectToVisible() requires a Rectangle (a subtype of >>> Rectangle2D), and modelToView() is deprecated with reference to >>> modelToView2D(), which returns a Rectangle2D, which is thus unusable >>> by scrollRectToVisible(). I also cannot find a way to create a new >>> Rectangle, given a Rectangle2D. >>> >>> In practice, under the hood, it's still just Rectangles (not >>> Rectangle2D). >>> >>> /Magnus >>> >>> On 2020-04-15 11:37, David Holmes wrote: >>>> Hi Magnus, >>>> >>>> This one sounds like it needs a Swing/Java2D developer to review it :) >>>> >>>> Cheers, >>>> David >>>> >>>> On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: >>>>> After JDK-8242804, a few places remain which are using deprecated >>>>> methods. They too should be fixed, and the deprecation warning >>>>> should no longer be disabled. >>>>> >>>>> This patch presupposes the fix for JDK-8242804 has been applied >>>>> (otherwise we cannot turn the deprecation warning back on). >>>>> >>>>> Some brief comments about each fix: >>>>> >>>>> * In ConstantPool.java, there was a boxing deprecation that I >>>>> missed in JDK-8242804 (sorry!) >>>>> >>>>> * In HighPrecisionJScrollBar.java, there is a trivial replacement >>>>> to use BigDecimal.divide with RoundingMode semantics. >>>>> >>>>> * In SourceCodePanel.java, I settled for suppressing the warning. >>>>> The issue here is that modelToView (which returns a Rectangle) is >>>>> deprecated in favor of modelToView2D, which returns a Rectangle2D >>>>> (which is a supertype of Rectangle). But we use the result in >>>>> scrollRectToVisible, and there exist no version of that which >>>>> accepts a Rectangle2D instead of a Rectangle, nor a way to created >>>>> a Rectangle from a Rectangle2D (that I could find). In practice, >>>>> this is just a game of types -- under the hood, modelToView2D >>>>> still returns a Rectangle (even though it only promises a >>>>> Rectangle2D). The alternative here would be to cast the result of >>>>> modelToView2D to a Rectangle, but I found that less attractive. >>>>> >>>>> * In JTreeTable.java, I've replaced the use of the old-style >>>>> modifier mask with the new-style extended modifier mask. To the >>>>> best of my understanding, this will just work the same for the >>>>> code here (and for the MouseEvent constructor, using the extended >>>>> mask is actually prescribed). >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 >>>>> >>>>> >>> > From erik.joelsson at oracle.com Wed Apr 15 13:42:24 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 15 Apr 2020 06:42:24 -0700 Subject: RFR: JDK-8242804 Fix trivial deprecation issues in jdk.hotspot.agent In-Reply-To: <9d8111bf-a286-d963-dc6d-3f80c7fcd4ae@oracle.com> References: <9d8111bf-a286-d963-dc6d-3f80c7fcd4ae@oracle.com> Message-ID: <26f05b89-8c30-f623-eef7-8682431785ec@oracle.com> Looks good. /Erik On 2020-04-15 01:18, Magnus Ihse Bursie wrote: > In the quest for getting rid of warning messages in jdk.hotspot.agent, > the time has now come for another major source of deprecation > messages, that are trivial to fix and might hide more tricky issues. > > This patch handles the "new Integer(42)" pattern of explicit boxing, > which is deprecated. I have fixed this using the improved autoboxing > functionality in modern Java (e.g. just "42"), wherever possible > (which was most places). For some cases, a modern factory method was > preferable. > > This patch also fixes newInstance() deprecation. > > As with the previous patches, it might be easier to just read the > patch file, > http://cr.openjdk.java.net/~ihse/JDK-8242804-SA-boxing-deprecations/webrev.01/open.patch. > (Fortunately, there are a log less changes in this patch than the > previous ones.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242804 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8242804-SA-boxing-deprecations/webrev.01 > > /Magnus From chris.plummer at oracle.com Wed Apr 15 17:28:56 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 15 Apr 2020 10:28:56 -0700 Subject: RFR(XS) 8230731: SA tests fail with "Windbg Error: ReadVirtual failed" Message-ID: <8e30b01d-b271-1775-b14e-085c0d347cfd@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8230731 http://cr.openjdk.java.net/~cjplummer/8230731/webrev.00/index.html SA reads in memory from the target process as needed. The lowest level API that reads in a page of memory on windows is WindbgDebuggerLocal.readBytesFromProcess0(). A typical stack when reading in a page looks like: ??????? at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readBytesFromProcess0(Native Method) ????????at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readBytesFromProcess(WindbgDebuggerLocal.java:482) ????????at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase$Fetcher.fetchPage(DebuggerBase.java:80) ????????at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getPage(PageCache.java:178) ????????at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63) ????????at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225) ????????at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:383) ????????at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) ????????at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:308) ????????at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:72) So readBytesFromProcess() and readBytesFromProcess0() are the only platform dependent bits, but all platforms implement them. Since SA does a lot of guess work to determine the validity of whatever it is looking at, this can result in an attempt to read at an address that is not even in the process. This is suppose to result in an AddressException, and then the SA code is suppose to handle that properly (assuming it was doing something where it wasn't sure if the address was valid). In the above stack trace, the AddressException (actually UnmappedAddressException) is suppose to be thrown by PageCache.getData(). This is suppose happen when a null result from readBytesFromProcess0() works its way up the call chain. This is how it has been working on all platforms...except windows. It's been throwing a DebuggerException from readBytesFromProcess0() if it failed. No one up the call chain knows how to handle it, so it ends up aborting whatever SA command was being executed. The right thing for readBytesFromProcess0() to do if it cannot read in the page is to return null like it does on all other platforms. It's expected that sometimes an attempt to read from an invalid address will be made, and null should be returned when this happens. With this fix, some tests that got "ReadVirtual failed", like ClhsdbScanOops, now pass. Others fail for different reasons because they do not expect the AddressException any more than they expected the DebuggerException. 8242787 [1] is one such reason for these failures, and will be fixed next. Note I could not get ClhsdbPstack.java to fail, which was mentioned in the CR a few times recently. I tried many 100s of times both with and without the fix and never saw it fail. However, looking at the PStack code, it looks like it will still print the exception (now an UnmappedAddressException instead of DebuggerException), and then continue on with the next thread to priont. But since it is no longer a DebuggerException, the test should pass (there is code in ClhsdbLauncher that makes it fail if it sees a DebuggerException). This relates to the email I just sent out yesterday regarding whether or not it is acceptable that sometimes SA can't print a thread's stack trace. I think it is, and this is an example case. This also fixes 8001227 [2], which I will close as a dup once I push. [1] https://bugs.openjdk.java.net/browse/JDK-8242787 [2] https://bugs.openjdk.java.net/browse/JDK-8001227 thanks, Chris From alexey.menkov at oracle.com Wed Apr 15 20:42:51 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 15 Apr 2020 13:42:51 -0700 Subject: RFR(XS) 8230731: SA tests fail with "Windbg Error: ReadVirtual failed" In-Reply-To: <8e30b01d-b271-1775-b14e-085c0d347cfd@oracle.com> References: <8e30b01d-b271-1775-b14e-085c0d347cfd@oracle.com> Message-ID: <8451d79b-6083-84bd-10a8-ffa755095c9d@oracle.com> Hi Chris, The fix looks good. --alex On 04/15/2020 10:28, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8230731 > http://cr.openjdk.java.net/~cjplummer/8230731/webrev.00/index.html > > SA reads in memory from the target process as needed. The lowest level > API that reads in a page of memory on windows is > WindbgDebuggerLocal.readBytesFromProcess0(). A typical stack when > reading in a page looks like: > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readBytesFromProcess0(Native > Method) > ????????at > jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readBytesFromProcess(WindbgDebuggerLocal.java:482) > > ????????at > jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase$Fetcher.fetchPage(DebuggerBase.java:80) > > ????????at > jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getPage(PageCache.java:178) > > ????????at > jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63) > > ????????at > jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225) > > ????????at > jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:383) > > ????????at > jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) > > ????????at > jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:308) > > ????????at > jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:72) > > > So readBytesFromProcess() and readBytesFromProcess0() are the only > platform dependent bits, but all platforms implement them. Since SA does > a lot of guess work to determine the validity of whatever it is looking > at, this can result in an attempt to read at an address that is not even > in the process. This is suppose to result in an AddressException, and > then the SA code is suppose to handle that properly (assuming it was > doing something where it wasn't sure if the address was valid). > > In the above stack trace, the AddressException (actually > UnmappedAddressException) is suppose to be thrown by > PageCache.getData(). This is suppose happen when a null result from > readBytesFromProcess0() works its way up the call chain. This is how it > has been working on all platforms...except windows. It's been throwing a > DebuggerException from readBytesFromProcess0() if it failed. No one up > the call chain knows how to handle it, so it ends up aborting whatever > SA command was being executed. > > The right thing for readBytesFromProcess0() to do if it cannot read in > the page is to return null like it does on all other platforms. It's > expected that sometimes an attempt to read from an invalid address will > be made, and null should be returned when this happens. > > With this fix, some tests that got "ReadVirtual failed", like > ClhsdbScanOops, now pass. Others fail for different reasons because they > do not expect the AddressException any more than they expected the > DebuggerException. 8242787 [1] is one such reason for these failures, > and will be fixed next. > > Note I could not get ClhsdbPstack.java to fail, which was mentioned in > the CR a few times recently. I tried many 100s of times both with and > without the fix and never saw it fail. However, looking at the PStack > code, it looks like it will still print the exception (now an > UnmappedAddressException instead of DebuggerException), and then > continue on with the next thread to priont. But since it is no longer a > DebuggerException, the test should pass (there is code in ClhsdbLauncher > that makes it fail if it sees a DebuggerException). This relates to the > email I just sent out yesterday regarding whether or not it is > acceptable that sometimes SA can't print a thread's stack trace. I think > it is, and this is an example case. > > This also fixes 8001227 [2], which I will close as a dup once I push. > > [1] https://bugs.openjdk.java.net/browse/JDK-8242787 > [2] https://bugs.openjdk.java.net/browse/JDK-8001227 > > thanks, > > Chris > > From serguei.spitsyn at oracle.com Wed Apr 15 21:40:08 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Apr 2020 14:40:08 -0700 Subject: RFR(XS) 8230731: SA tests fail with "Windbg Error: ReadVirtual failed" In-Reply-To: <8451d79b-6083-84bd-10a8-ffa755095c9d@oracle.com> References: <8e30b01d-b271-1775-b14e-085c0d347cfd@oracle.com> <8451d79b-6083-84bd-10a8-ffa755095c9d@oracle.com> Message-ID: <9801c7e3-8566-06c8-f345-fbd33bf3b4a3@oracle.com> Hi Chris, LGTM++ Thanks, Serguei On 4/15/20 13:42, Alex Menkov wrote: > Hi Chris, > > The fix looks good. > > --alex > > On 04/15/2020 10:28, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8230731 >> http://cr.openjdk.java.net/~cjplummer/8230731/webrev.00/index.html >> >> SA reads in memory from the target process as needed. The lowest >> level API that reads in a page of memory on windows is >> WindbgDebuggerLocal.readBytesFromProcess0(). A typical stack when >> reading in a page looks like: >> >> ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readBytesFromProcess0(Native >> Method) >> ?????????at >> jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readBytesFromProcess(WindbgDebuggerLocal.java:482) >> >> ?????????at >> jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase$Fetcher.fetchPage(DebuggerBase.java:80) >> >> ?????????at >> jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getPage(PageCache.java:178) >> >> ?????????at >> jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63) >> >> ?????????at >> jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225) >> >> ?????????at >> jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:383) >> >> ?????????at >> jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) >> >> ?????????at >> jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:308) >> >> ?????????at >> jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:72) >> >> >> So readBytesFromProcess() and readBytesFromProcess0() are the only >> platform dependent bits, but all platforms implement them. Since SA >> does a lot of guess work to determine the validity of whatever it is >> looking at, this can result in an attempt to read at an address that >> is not even in the process. This is suppose to result in an >> AddressException, and then the SA code is suppose to handle that >> properly (assuming it was doing something where it wasn't sure if the >> address was valid). >> >> In the above stack trace, the AddressException (actually >> UnmappedAddressException) is suppose to be thrown by >> PageCache.getData(). This is suppose happen when a null result from >> readBytesFromProcess0() works its way up the call chain. This is how >> it has been working on all platforms...except windows. It's been >> throwing a DebuggerException from readBytesFromProcess0() if it >> failed. No one up the call chain knows how to handle it, so it ends >> up aborting whatever SA command was being executed. >> >> The right thing for readBytesFromProcess0() to do if it cannot read >> in the page is to return null like it does on all other platforms. >> It's expected that sometimes an attempt to read from an invalid >> address will be made, and null should be returned when this happens. >> >> With this fix, some tests that got "ReadVirtual failed", like >> ClhsdbScanOops, now pass. Others fail for different reasons because >> they do not expect the AddressException any more than they expected >> the DebuggerException. 8242787 [1] is one such reason for these >> failures, and will be fixed next. >> >> Note I could not get ClhsdbPstack.java to fail, which was mentioned >> in the CR a few times recently. I tried many 100s of times both with >> and without the fix and never saw it fail. However, looking at the >> PStack code, it looks like it will still print the exception (now an >> UnmappedAddressException instead of DebuggerException), and then >> continue on with the next thread to priont. But since it is no longer >> a DebuggerException, the test should pass (there is code in >> ClhsdbLauncher that makes it fail if it sees a DebuggerException). >> This relates to the email I just sent out yesterday regarding whether >> or not it is acceptable that sometimes SA can't print a thread's >> stack trace. I think it is, and this is an example case. >> >> This also fixes 8001227 [2], which I will close as a dup once I push. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8242787 >> [2] https://bugs.openjdk.java.net/browse/JDK-8001227 >> >> thanks, >> >> Chris >> >> From chris.plummer at oracle.com Wed Apr 15 21:42:39 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 15 Apr 2020 14:42:39 -0700 Subject: RFR(XS) 8230731: SA tests fail with "Windbg Error: ReadVirtual failed" In-Reply-To: <9801c7e3-8566-06c8-f345-fbd33bf3b4a3@oracle.com> References: <8e30b01d-b271-1775-b14e-085c0d347cfd@oracle.com> <8451d79b-6083-84bd-10a8-ffa755095c9d@oracle.com> <9801c7e3-8566-06c8-f345-fbd33bf3b4a3@oracle.com> Message-ID: Thanks Serguei and Alex! On 4/15/20 2:40 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > LGTM++ > > Thanks, > Serguei > > > On 4/15/20 13:42, Alex Menkov wrote: >> Hi Chris, >> >> The fix looks good. >> >> --alex >> >> On 04/15/2020 10:28, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8230731 >>> http://cr.openjdk.java.net/~cjplummer/8230731/webrev.00/index.html >>> >>> SA reads in memory from the target process as needed. The lowest >>> level API that reads in a page of memory on windows is >>> WindbgDebuggerLocal.readBytesFromProcess0(). A typical stack when >>> reading in a page looks like: >>> >>> ???????? at >>> jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readBytesFromProcess0(Native >>> Method) >>> ?????????at >>> jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readBytesFromProcess(WindbgDebuggerLocal.java:482) >>> >>> ?????????at >>> jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase$Fetcher.fetchPage(DebuggerBase.java:80) >>> >>> ?????????at >>> jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getPage(PageCache.java:178) >>> >>> ?????????at >>> jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63) >>> >>> ?????????at >>> jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225) >>> >>> ?????????at >>> jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:383) >>> >>> ?????????at >>> jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) >>> >>> ?????????at >>> jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:308) >>> >>> ?????????at >>> jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:72) >>> >>> >>> So readBytesFromProcess() and readBytesFromProcess0() are the only >>> platform dependent bits, but all platforms implement them. Since SA >>> does a lot of guess work to determine the validity of whatever it is >>> looking at, this can result in an attempt to read at an address that >>> is not even in the process. This is suppose to result in an >>> AddressException, and then the SA code is suppose to handle that >>> properly (assuming it was doing something where it wasn't sure if >>> the address was valid). >>> >>> In the above stack trace, the AddressException (actually >>> UnmappedAddressException) is suppose to be thrown by >>> PageCache.getData(). This is suppose happen when a null result from >>> readBytesFromProcess0() works its way up the call chain. This is how >>> it has been working on all platforms...except windows. It's been >>> throwing a DebuggerException from readBytesFromProcess0() if it >>> failed. No one up the call chain knows how to handle it, so it ends >>> up aborting whatever SA command was being executed. >>> >>> The right thing for readBytesFromProcess0() to do if it cannot read >>> in the page is to return null like it does on all other platforms. >>> It's expected that sometimes an attempt to read from an invalid >>> address will be made, and null should be returned when this happens. >>> >>> With this fix, some tests that got "ReadVirtual failed", like >>> ClhsdbScanOops, now pass. Others fail for different reasons because >>> they do not expect the AddressException any more than they expected >>> the DebuggerException. 8242787 [1] is one such reason for these >>> failures, and will be fixed next. >>> >>> Note I could not get ClhsdbPstack.java to fail, which was mentioned >>> in the CR a few times recently. I tried many 100s of times both with >>> and without the fix and never saw it fail. However, looking at the >>> PStack code, it looks like it will still print the exception (now an >>> UnmappedAddressException instead of DebuggerException), and then >>> continue on with the next thread to priont. But since it is no >>> longer a DebuggerException, the test should pass (there is code in >>> ClhsdbLauncher that makes it fail if it sees a DebuggerException). >>> This relates to the email I just sent out yesterday regarding >>> whether or not it is acceptable that sometimes SA can't print a >>> thread's stack trace. I think it is, and this is an example case. >>> >>> This also fixes 8001227 [2], which I will close as a dup once I push. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8242787 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8001227 >>> >>> thanks, >>> >>> Chris >>> >>> > From coleen.phillimore at oracle.com Thu Apr 16 00:59:25 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Apr 2020 20:59:25 -0400 Subject: RFR (T) 8242896: typo #ifdef INCLUDE_JVMTI in codeCache.cpp Message-ID: open webrev at http://cr.openjdk.java.net/~coleenp/2020/8242896.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8242896 Built and ran vmTestbase RedefineTests which use the protected code. thanks, Coleen From david.holmes at oracle.com Thu Apr 16 01:37:32 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Apr 2020 11:37:32 +1000 Subject: RFR (T) 8242896: typo #ifdef INCLUDE_JVMTI in codeCache.cpp In-Reply-To: References: Message-ID: Hi Coleen, On 16/04/2020 10:59 am, coleen.phillimore at oracle.com wrote: > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8242896.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8242896 Looks good but ... > Built and ran vmTestbase RedefineTests which use the protected code. ... you need to ensure that builds that don't INCLUDE_JVMTI still work okay as they will now actually be excluding this code for the first time. Thanks, David > thanks, > Coleen From coleen.phillimore at oracle.com Thu Apr 16 02:37:34 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Apr 2020 22:37:34 -0400 Subject: RFR (T) 8242896: typo #ifdef INCLUDE_JVMTI in codeCache.cpp In-Reply-To: References: Message-ID: <048f98a3-4c8c-f691-6aa1-44d72b3020f3@oracle.com> On 4/15/20 9:37 PM, David Holmes wrote: > Hi Coleen, > > On 16/04/2020 10:59 am, coleen.phillimore at oracle.com wrote: >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8242896.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8242896 > > Looks good but ... > >> Built and ran vmTestbase RedefineTests which use the protected code. > > ... you need to ensure that builds that don't INCLUDE_JVMTI still work > okay as they will now actually be excluding this code for the first time. Last time I tried to build minimal, it failed for some odd problem on my system.? I'll wait until someone from the openjdk can build it then. thanks, Coleen > > Thanks, > David > >> thanks, >> Coleen From coleen.phillimore at oracle.com Thu Apr 16 02:40:13 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Apr 2020 22:40:13 -0400 Subject: RFR (S) 8074292: nsk/jdb/kill/kill001: generateOopMap.cpp assert(bb->is_reachable()) failed In-Reply-To: <0a87b7cd-7dfe-0831-05e1-8d48f5eb6755@oracle.com> References: <6e38070c-f166-a0c2-8b8d-d698e5f5bcf3@oracle.com> <1e3d4907-d54a-df0e-e0d3-8bbda8c5394a@oracle.com> <0a87b7cd-7dfe-0831-05e1-8d48f5eb6755@oracle.com> Message-ID: <102f0511-9172-ef0e-5f26-003600c322c2@oracle.com> On 4/15/20 1:28 AM, David Holmes wrote: > On 14/04/2020 10:36 pm, coleen.phillimore at oracle.com wrote: >> On 4/13/20 10:49 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 14/04/2020 12:34 am, coleen.phillimore at oracle.com wrote: >>>> Summary: Do not install async exceptions at_safepoint for each >>>> bytecode. >>> >>> I'm still not certain that we have to go this far to solve this >>> problem, but it does sound like a relatively simple solution >>> provided there are no unintended consequences. >>> >>>> See CR for a lot more details.? This change calls a new >>>> InterpreterRuntime::at_safepoint_async_safe() which installs the >>>> async exception in the interpreter at backward branches and >>>> returns. This uses safepoint polling code in the interpreter for >>>> each platform.? These changes (cross) compile on platforms that >>>> Oracle doesn't support but I don't know if they work. >>>> >>>> I'm not convinced the platform specific changes are necessary, >>>> because calls to the runtime from many bytecodes will install the >>>> async exception, so it's essentially installed "enough" for this >>>> deprecated feature.? I tested the changes with *and* without the >>>> platform specific changes with no failure, which included the jdb, >>>> jdi and jvmti serviceability tests. >>> >>> I don't understand what you mean here. If the whole basis of this >>> fix is "don't install async exceptions other than at backward >>> branches and returns" then how is that implemented without the >>> changes in the interpreter code? >>> >>> If this can be fixed just by adjusting the actual monitor code then >>> I would much prefer that. It took me a while to get my head around >>> the dispatch changes in interpreter code and even then I don't see >>> how those changes only impact backward branches and returns ?? >> >> You have to read the comments in the bug again.? There *is* special >> code to not install the async exception in the monitorexit code. That >> is not enough to prevent this bug.? You can also read the old bug >> report you linked to this one. > > I know there is some special handling in monitorexit already, I was > referring to additional special handling around the monitorexit to > disable whatever piece of code is currently installing the async > exception. David pointed out to me offline that the bytecode after monitorexit was not part of the exception region (see bug comments for details). I'm withdrawing this RFR. Coleen > >> The interpreter code dispatch_next passes "true" if it's a backwards >> branch, that's how it can tell. > > Okay - I see dispatch_next is passed generate_poll=true for returns > but I can't see where backward branches come into play. Your changes > cause the at_safepoint_async_safe to be called in that case, whereas > any other code paths that lead to at_safepoint no longer install the > async exception. So things are a bit clearer in that regard. > >> My point was that there are enough code paths that install async >> exceptions *other than monitorenter and monitorexit* that maybe it's >> not necessary to install them at backwards branches and returns.? I >> suppose someone could construct a test case to show otherwise. > > Yes I understood that was the query, but without knowing exactly where > those code paths are it is hard to comment on whether there is > adequate coverage. Even with installing on backward branches there is > a risk that small loops can be unrolled and so lose the check (indeed > that is what "counted loops" in the JIT does) and thus we rely on > these other code paths anyway. > >>>> This change also makes InterpreterRuntime::monitorexit a JRT_LEAF >>>> bytecode. The code to check for exceptions is outside the runtime >>>> call. I ran the JCK vm and lang tests on this change with no failure. >>>> >>>> Tested with tier1-6. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8074292.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8074292 >>> >>> ./cpu/x86/interp_masm_x86.cpp >>> >>> It took me a long time to figure out how the new logic worked >>> compared to the old logic. Even then I'm unclear about the effective >>> recursive dispatch path: dispatch_base(generate_poll=true) -> >>> dispatch_via -> dispatch_base(generate_poll=false) - does it work >>> okay with VerifyActivationFrameSize? It seems a rather convoluted >>> way to effectively just execute: >>> >>> ?858?? lea(rscratch1, ExternalAddress((address)table)); >>> ?859?? jmp(Address(rscratch1, rbx, Address::times_8)); >> >> I could test it with VerifyActivationFrameSize.? Or I could just add >> the two instructions per platform.? I mostly copied the code in >> generate_safept_entry_for.? It might be better to just copy the >> instructions. >> >>> >>> --- >>> >>> src/hotspot/share/interpreter/interpreterRuntime.cpp >>> >>> How were you able to drop this code: >>> >>> 791?? if (elem == NULL || h_obj()->is_unlocked()) { >>> 792 THROW(vmSymbols::java_lang_IllegalMonitorStateException()); >>> 793?? } >>> >>> ? >>> ?and this: >> >> The caller throws the exception for these cases. > > Sorry but I don't see that in the caller e.g. > InterpreterMacroAssembler::unlock_object. Further you are not allowing > for elem to be NULL which will lead to a crash when you dereference it. > >>> >>> 798 #ifdef ASSERT >>> 799 thread->last_frame().interpreter_frame_verify_monitor(elem); >>> 800 #endif >>> >> >> This seemed redundant. > > Possibly, but I assume the pairing in monitorenter and monitorexit > around the actual monitor operation is to ensure that the stack frame > info is not unexpectedly messed up. Maybe it is redundant to call > before and after, but then maybe the same is true in monitorenter. > > David > ----- > >> Coleen >>> ? >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>> >> From joe.darcy at oracle.com Thu Apr 16 05:29:21 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 15 Apr 2020 22:29:21 -0700 Subject: RFR: JDK-8242804 Fix trivial deprecation issues in jdk.hotspot.agent In-Reply-To: <9d8111bf-a286-d963-dc6d-3f80c7fcd4ae@oracle.com> References: <9d8111bf-a286-d963-dc6d-3f80c7fcd4ae@oracle.com> Message-ID: Looks fine Magnus; thanks, -Joe On 4/15/2020 1:18 AM, Magnus Ihse Bursie wrote: > In the quest for getting rid of warning messages in jdk.hotspot.agent, > the time has now come for another major source of deprecation > messages, that are trivial to fix and might hide more tricky issues. > > This patch handles the "new Integer(42)" pattern of explicit boxing, > which is deprecated. I have fixed this using the improved autoboxing > functionality in modern Java (e.g. just "42"), wherever possible > (which was most places). For some cases, a modern factory method was > preferable. > > This patch also fixes newInstance() deprecation. > > As with the previous patches, it might be easier to just read the > patch file, > http://cr.openjdk.java.net/~ihse/JDK-8242804-SA-boxing-deprecations/webrev.01/open.patch. > (Fortunately, there are a log less changes in this patch than the > previous ones.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242804 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8242804-SA-boxing-deprecations/webrev.01 > > /Magnus From serguei.spitsyn at oracle.com Thu Apr 16 06:15:38 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Apr 2020 23:15:38 -0700 Subject: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent In-Reply-To: <7e66a73d-910c-52f7-683b-f6964c4942b2@oracle.com> References: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com> <194c6cca-f6c5-5250-3dbf-5c03036c3280@oracle.com> <7e66a73d-910c-52f7-683b-f6964c4942b2@oracle.com> Message-ID: <6a4ed2c8-61ee-3199-adb6-e17f0e87b181@oracle.com> Hi Magnus, It looks good to me. Thanks, Serguei On 4/15/20 06:00, Magnus Ihse Bursie wrote: > Here is an updated version, that avoids the SuppressWarnings for > modelToView: > > http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.02 > > > (Only change is in SourceCodePanel.java compared to v01) > > /Magnus > > On 2020-04-15 14:30, Magnus Ihse Bursie wrote: >> >> >> On 2020-04-15 12:59, Prasanta Sadhukhan wrote: >>> Hi Magnus, >>> >>> Why can't we just use modelToView2D() to get Rectangle2D and then >>> cast to Rectangle tobe used in scrollRectToVisible() or else use >>> (int)Rectangle2D.getX(), (int)getY(), getWidth(), getHeight() to >>> construct a new Rectangle()? >> Casting a Rectangle2D to a Rectangle does not seem to me to be an >> improvement. That presupposes even more knowledge about >> implementation details. >> >> However, I'll look into constructing a Rectangle using the getters >> from the Rectangle2D, as you suggested. Thanks! >> >> /Magnus >>> >>> Regard >>> Prasanta >>> On 15-Apr-20 3:35 PM, Magnus Ihse Bursie wrote: >>>> Hi swing-dev, >>>> >>>> Do you have any other suggestions for how to resolve the >>>> deprecation of modelToView() in this code? >>>> >>>> Basically, the code does this: >>>> >>>> ?????? Rectangle rect = source.modelToView(offset); >>>> ?????? source.scrollRectToVisible(rect); >>>> >>>> but scrollRectToVisible() requires a Rectangle (a subtype of >>>> Rectangle2D), and modelToView() is deprecated with reference to >>>> modelToView2D(), which returns a Rectangle2D, which is thus >>>> unusable by scrollRectToVisible(). I also cannot find a way to >>>> create a new Rectangle, given a Rectangle2D. >>>> >>>> In practice, under the hood, it's still just Rectangles (not >>>> Rectangle2D). >>>> >>>> /Magnus >>>> >>>> On 2020-04-15 11:37, David Holmes wrote: >>>>> Hi Magnus, >>>>> >>>>> This one sounds like it needs a Swing/Java2D developer to review >>>>> it :) >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: >>>>>> After JDK-8242804, a few places remain which are using deprecated >>>>>> methods. They too should be fixed, and the deprecation warning >>>>>> should no longer be disabled. >>>>>> >>>>>> This patch presupposes the fix for JDK-8242804 has been applied >>>>>> (otherwise we cannot turn the deprecation warning back on). >>>>>> >>>>>> Some brief comments about each fix: >>>>>> >>>>>> * In ConstantPool.java, there was a boxing deprecation that I >>>>>> missed in JDK-8242804 (sorry!) >>>>>> >>>>>> * In HighPrecisionJScrollBar.java, there is a trivial replacement >>>>>> to use BigDecimal.divide with RoundingMode semantics. >>>>>> >>>>>> * In SourceCodePanel.java, I settled for suppressing the warning. >>>>>> The issue here is that modelToView (which returns a Rectangle) is >>>>>> deprecated in favor of modelToView2D, which returns a Rectangle2D >>>>>> (which is a supertype of Rectangle). But we use the result in >>>>>> scrollRectToVisible, and there exist no version of that which >>>>>> accepts a Rectangle2D instead of a Rectangle, nor a way to >>>>>> created a Rectangle from a Rectangle2D (that I could find). In >>>>>> practice, this is just a game of types -- under the hood, >>>>>> modelToView2D still returns a Rectangle (even though it only >>>>>> promises a Rectangle2D). The alternative here would be to cast >>>>>> the result of modelToView2D to a Rectangle, but I found that less >>>>>> attractive. >>>>>> >>>>>> * In JTreeTable.java, I've replaced the use of the old-style >>>>>> modifier mask with the new-style extended modifier mask. To the >>>>>> best of my understanding, this will just work the same for the >>>>>> code here (and for the MouseEvent constructor, using the extended >>>>>> mask is actually prescribed). >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 >>>>>> WebRev: >>>>>> http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 >>>>>> >>>>>> >>>> >> > From sgehwolf at redhat.com Thu Apr 16 08:40:15 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 16 Apr 2020 10:40:15 +0200 Subject: RFR: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker In-Reply-To: <1408ACE5-DA99-4687-94A8-5C659287BC3C@tencent.com> References: <1408ACE5-DA99-4687-94A8-5C659287BC3C@tencent.com> Message-ID: <5c3ddfe95359a674d1cc0b9984bfd437c3f3a173.camel@redhat.com> Hi Jie, On Fri, 2020-04-10 at 01:49 +0000, jiefu(??) wrote: > Hi all, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242480 > Webrev: http://cr.openjdk.java.net/~jiefu/8242480/webrev.00/ > > Negative values were returned by getFreeSwapSpaceSize() in our docker testing. > The reason is that current implementation doesn't consider the situation when memory.limit_in_bytes == memory.memsw.limit_in_bytes, which means do not use the swap space at all. > > In src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java, let's see > ------------------------------------------------ > 71 public long getFreeSwapSpaceSize() { > 72 if (containerMetrics != null) { > 73 long memSwapLimit = containerMetrics.getMemoryAndSwapLimit(); > 74 long memLimit = containerMetrics.getMemoryLimit(); > 75 if (memSwapLimit >= 0 && memLimit >= 0) { > 76 for (int attempt = 0; attempt < MAX_ATTEMPTS_NUMBER; attempt++) { > 77 long memSwapUsage = containerMetrics.getMemoryAndSwapUsage(); > 78 long memUsage = containerMetrics.getMemoryUsage(); > 79 if (memSwapUsage > 0 && memUsage > 0) { > 80 // We read "memory usage" and "memory and swap usage" not atomically, > 81 // and it's possible to get the negative value when subtracting these two. > 82 // If this happens just retry the loop for a few iterations. > 83 if ((memSwapUsage - memUsage) >= 0) { > 84 return memSwapLimit - memLimit - (memSwapUsage - memUsage); > 85 } > 86 } > 87 } > 88 } > 89 } > 90 return getFreeSwapSpaceSize0(); > 91 } > ------------------------------------------------ > If memSwapLimit (@line 73) equals memLimit (@line 74), then getFreeSwapSpaceSize() may return a negative value @line 84. > > It would be better to fix it. > Could you please review it and give me some advice? Would this be reproducible via a test? There is test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java which contains testOperatingSystemMXBeanAwareness() tests. It would be good to capture this in a test somehow. Thanks, Severin From magnus.ihse.bursie at oracle.com Thu Apr 16 12:47:35 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 16 Apr 2020 14:47:35 +0200 Subject: RFR: JDK-8242943 Fix all remaining unchecked warnings in jdk.hotspot.agent Message-ID: This is the final part of removing all warnings from the build of jdk.hotspot.agent. This patch includes a number of non-trivial fixes for the few remaining unchecked warnings. The good news is that with this fix (and after the recent removal of Nashorn and rmic), the JDK build is finally complete free from warnings for the first time ever! EPIC!!!!!1!!! :-) The bad news is that this patch is probably the most complex of all I've posted so far. :-/ I'll break down the changes in four groups: * ConstMethod superclass issue ConstMethod current extends VMObject. However, it is treated as a Metadata (Metadata is a subtype of VMObject). For instance, this code appears in Metadata.java: ? metadataConstructor.addMapping("ConstMethod", ConstMethod.class); I believe it is just an oversight that ConstMethod does not also extend Metadata like the rest of the classes added to the metadataConstructor mapping, one which has not been caught without the extra type safety given by generics. * ProfileData casting In several places, a ProfileData item is extracted from a collection, its type checked with instanceof, and then acted on accordingly. (Yeah, nice and clean OOP abstraction at work! :-)) This works well most of the time, but when casting to ReceiverTypeData or CallTypeDataInterface, the type include generic parametrisation, so it needs to be cast to e.g. ReceiverTypeData. Unfortunately, this cannot be verified using instanceof, due to generic type erasure, and thus the compiler considers this an unchecked cast. (At least, this is my understanding of what is happening.) As far as I can tell, this is legitimate code, and the only way to really handle this (barring a more extensive rewrite) is to disable the warning for these cases. * Generification of the InstanceConstructor hierarchy I have properly generified the InstanceConstructor hierarchy, with the VirtualConstructor, StaticBaseConstructor and VirtualBaseConstructor subclasses. (And also the related helper class VMObjectFactory.) Most of it turned out OK (and with improved type safety), but there was one piece of code that is a bit unfortunate. In VirtualBaseConstructor, we have the following: ??????????? @SuppressWarnings("unchecked") ??????????? Class lookedUpClass = (Class)Class.forName(packageName + "." + superType.getName()); ??????????? c = lookedUpClass; That is, we send in a name for a class and assumes that it will resolve to a subtype of T, but there is no way to enforce this with type safety. I have verified all current callers to the constructor so that they all abide to this rule (of course, otherwise the code would not have worked, but I checked it anyway). The alternative to suppressing the warning is to redesign the entire API, so we do not send in a class name, but instead a Class, and use that to extract the name instead. At this point, I don't find it worth it. This is, after all, no worse than it was before. * SortableTableModel and TableModelComparator This one was quite messy. The tables are being used in quite different ways in different places, which made it hard to generify in a good way. A lot of it revolves around keeping the data as Objects and casting it to a known type. (Some of this behavior comes from the fact that they extend old Swing classes which does this.) I've tried to tighten it up as much as possible by introducing increased type safety by generification, but in the end, it was not fully possible to do without a major surgery of the entire class structure. As above, most of it turned out OK, but not all. The tricky one here is the helper TableModelComparator. This one took me a while to wrap my head around. It implements Comparator, but the compare() method takes "rows" from the model, which are just expressed as Objects, and left to subclasses to define differently. For one of the subclasses it uses the type T that the TableModel is created around, but in other it uses an independent domain model. :-/ Anyway. The compare() method then extracts data for the individual columns of each row using the method getValueForColumn(), and compare them pairwise. This data from the rows are supposed to implement Comparable. In the end, I think I got it pretty OK, but I'm still an apprentice when it comes to generics black magic. The subclasses of TableModelComparator want to return different objects from getValueForColumn() for different columns in the row, like Long or String. They are all Comparable, but String is Comparable and Long is Comparable. So I needed to specify the abstract method as returning Comparable, since Comparable is not Comparable. But then, for reasons that I do not fully fathom, I could not specify Comparable o1 = getValueForColumn(row1, columns[i]); Comparable o2 = getValueForColumn(row2, columns[i]); int result = o1.compareTo(o2); because the compiler did not accept the call to compareTo(). I did try to sacrifice a black rooster at midnight and walking backwards in a circle three time, to no avail. Maybe the problem was that it was not full moon or that I have no cat. In the end, I casted o1 and o2 to Comparable and suppressed the warning for that cast. If anyone knows what rituals I need to perform to make this work, or -- even better -- how to fix the code properly, please let me know! Bug: https://bugs.openjdk.java.net/browse/JDK-8242943 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8242943-SA-final-unchecked-warnings/webrev.01 /Magnus From jiefu at tencent.com Thu Apr 16 13:23:37 2020 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Thu, 16 Apr 2020 13:23:37 +0000 Subject: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker(Internet mail) Message-ID: <7EABDE84-236C-44B9-8599-C7131456131F@tencent.com> Hi Severin, Thanks for your review and very nice suggestions. Updated: http://cr.openjdk.java.net/~jiefu/8242480/webrev.01/ test/hotspot/jtreg/containers/docker/TestGetFreeSwapSpaceSize.java is added to reproduce the bug. Thanks a lot. Best regards, Jie ?On 2020/4/16, 4:40 PM, "Severin Gehwolf" wrote: Hi Jie, On Fri, 2020-04-10 at 01:49 +0000, jiefu(??) wrote: > Hi all, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242480 > Webrev: http://cr.openjdk.java.net/~jiefu/8242480/webrev.00/ > > Negative values were returned by getFreeSwapSpaceSize() in our docker testing. > The reason is that current implementation doesn't consider the situation when memory.limit_in_bytes == memory.memsw.limit_in_bytes, which means do not use the swap space at all. > > In src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java, let's see > ------------------------------------------------ > 71 public long getFreeSwapSpaceSize() { > 72 if (containerMetrics != null) { > 73 long memSwapLimit = containerMetrics.getMemoryAndSwapLimit(); > 74 long memLimit = containerMetrics.getMemoryLimit(); > 75 if (memSwapLimit >= 0 && memLimit >= 0) { > 76 for (int attempt = 0; attempt < MAX_ATTEMPTS_NUMBER; attempt++) { > 77 long memSwapUsage = containerMetrics.getMemoryAndSwapUsage(); > 78 long memUsage = containerMetrics.getMemoryUsage(); > 79 if (memSwapUsage > 0 && memUsage > 0) { > 80 // We read "memory usage" and "memory and swap usage" not atomically, > 81 // and it's possible to get the negative value when subtracting these two. > 82 // If this happens just retry the loop for a few iterations. > 83 if ((memSwapUsage - memUsage) >= 0) { > 84 return memSwapLimit - memLimit - (memSwapUsage - memUsage); > 85 } > 86 } > 87 } > 88 } > 89 } > 90 return getFreeSwapSpaceSize0(); > 91 } > ------------------------------------------------ > If memSwapLimit (@line 73) equals memLimit (@line 74), then getFreeSwapSpaceSize() may return a negative value @line 84. > > It would be better to fix it. > Could you please review it and give me some advice? Would this be reproducible via a test? There is test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java which contains testOperatingSystemMXBeanAwareness() tests. It would be good to capture this in a test somehow. Thanks, Severin From magnus.ihse.bursie at oracle.com Thu Apr 16 14:24:28 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 16 Apr 2020 16:24:28 +0200 Subject: RFR (T) 8242896: typo #ifdef INCLUDE_JVMTI in codeCache.cpp In-Reply-To: <048f98a3-4c8c-f691-6aa1-44d72b3020f3@oracle.com> References: <048f98a3-4c8c-f691-6aa1-44d72b3020f3@oracle.com> Message-ID: On 2020-04-16 04:37, coleen.phillimore at oracle.com wrote: > > > On 4/15/20 9:37 PM, David Holmes wrote: >> Hi Coleen, >> >> On 16/04/2020 10:59 am, coleen.phillimore at oracle.com wrote: >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8242896.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8242896 >> >> Looks good but ... >> >>> Built and ran vmTestbase RedefineTests which use the protected code. >> >> ... you need to ensure that builds that don't INCLUDE_JVMTI still >> work okay as they will now actually be excluding this code for the >> first time. > > Last time I tried to build minimal, it failed for some odd problem on > my system.? I'll wait until someone from the openjdk can build it then. > thanks, Building minimal should work.? Try something like this: "jib configure -- --with-jvm-variants=minimal". It should work. I just tried with your patch, and it does not work. /localhome/hg/jdk-BAR/open/src/hotspot/share/classfile/metadataOnStackMark.cpp:70: error: undefined reference to 'CodeCache::old_nmethods_do(MetadataClosure*)' /localhome/hg/jdk-BAR/open/src/hotspot/share/code/nmethod.cpp:1495: error: undefined reference to 'CodeCache::unregister_old_nmethod(CompiledMethod*)' I made a quick check but it was not clear to me if the call sites in metadataOnStackMark.cpp and nmethod.cpp should be excluded if missing jvmti, or if the code in codeCache.cpp should really be present even with jvmti. /Magnus > Coleen >> >> Thanks, >> David >> >>> thanks, >>> Coleen > From coleen.phillimore at oracle.com Thu Apr 16 15:14:11 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 16 Apr 2020 11:14:11 -0400 Subject: RFR (T) 8242896: typo #ifdef INCLUDE_JVMTI in codeCache.cpp In-Reply-To: References: <048f98a3-4c8c-f691-6aa1-44d72b3020f3@oracle.com> Message-ID: On 4/16/20 10:24 AM, Magnus Ihse Bursie wrote: > On 2020-04-16 04:37, coleen.phillimore at oracle.com wrote: >> >> >> On 4/15/20 9:37 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 16/04/2020 10:59 am, coleen.phillimore at oracle.com wrote: >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8242896.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8242896 >>> >>> Looks good but ... >>> >>>> Built and ran vmTestbase RedefineTests which use the protected code. >>> >>> ... you need to ensure that builds that don't INCLUDE_JVMTI still >>> work okay as they will now actually be excluding this code for the >>> first time. >> >> Last time I tried to build minimal, it failed for some odd problem on >> my system.? I'll wait until someone from the openjdk can build it then. >> thanks, > Building minimal should work.? Try something like this: "jib configure > -- --with-jvm-variants=minimal". It should work. I used to get some error about some X11 library.? I don't remember what it was.? Now I get this warning: The following warnings were produced. Repeated here for convenience: WARNING: Ignoring value of PERL from the environment. Use command line variables instead. I'm not sure what it means but it seems to be building. > > I just tried with your patch, and it does not work. > > /localhome/hg/jdk-BAR/open/src/hotspot/share/classfile/metadataOnStackMark.cpp:70: > error: undefined reference to > 'CodeCache::old_nmethods_do(MetadataClosure*)' > /localhome/hg/jdk-BAR/open/src/hotspot/share/code/nmethod.cpp:1495: > error: undefined reference to > 'CodeCache::unregister_old_nmethod(CompiledMethod*)' > > I made a quick check but it was not clear to me if the call sites in > metadataOnStackMark.cpp and nmethod.cpp should be excluded if missing > jvmti, or if the code in codeCache.cpp should really be present even > with jvmti. They should be excluded. Thanks for testing it for me.? Now it builds (up to that point).? Hopefully still trivial. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8242896.02/webrev Thanks! Coleen > > /Magnus > > >> Coleen >>> >>> Thanks, >>> David >>> >>>> thanks, >>>> Coleen >> > From sgehwolf at redhat.com Thu Apr 16 15:39:40 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 16 Apr 2020 17:39:40 +0200 Subject: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker(Internet mail) In-Reply-To: <7EABDE84-236C-44B9-8599-C7131456131F@tencent.com> References: <7EABDE84-236C-44B9-8599-C7131456131F@tencent.com> Message-ID: Hi Jie, On Thu, 2020-04-16 at 13:23 +0000, jiefu(??) wrote: > Hi Severin, > > Thanks for your review and very nice suggestions. Thanks for adding a test! > Updated: http://cr.openjdk.java.net/~jiefu/8242480/webrev.01/ > > test/hotspot/jtreg/containers/docker/TestGetFreeSwapSpaceSize.java is > added to reproduce the bug. Since you've added a new test, please move them to the jdk docker tests in: test/jdk/jdk/internal/platform/docker/ This is because the OperatingSystemMXBean uses the Metrics.java internal API (not hotspot cgroup support) and the tests really belong there alongside other Metrics docker tests. test/hotspot/jtreg/containers/docker/TestGetFreeSwapSpaceSize.java + * @build sun.hotspot.WhiteBox GetFreeSwapSpaceSize + * @run driver ClassFileInstaller -jar whitebox.jar sun.hotspot.WhiteBox sun.hotspot.WhiteBox$WhiteBoxPermission I don't see any reason why WhiteBox would be needed for this test. Is that an oversight or am I missing something? Thanks, Severin > Thanks a lot. > Best regards, > Jie > > > ?On 2020/4/16, 4:40 PM, "Severin Gehwolf" > wrote: > > Hi Jie, > > On Fri, 2020-04-10 at 01:49 +0000, jiefu(??) wrote: > > Hi all, > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242480 > > Webrev: http://cr.openjdk.java.net/~jiefu/8242480/webrev.00/ > > > > Negative values were returned by getFreeSwapSpaceSize() in our > docker testing. > > The reason is that current implementation doesn't consider the > situation when memory.limit_in_bytes == memory.memsw.limit_in_bytes, > which means do not use the swap space at all. > > > > In > src/jdk.management/unix/classes/com/sun/management/internal/Operating > SystemImpl.java, let's see > > ------------------------------------------------ > > 71 public long getFreeSwapSpaceSize() { > > 72 if (containerMetrics != null) { > > 73 long memSwapLimit = > containerMetrics.getMemoryAndSwapLimit(); > > 74 long memLimit = > containerMetrics.getMemoryLimit(); > > 75 if (memSwapLimit >= 0 && memLimit >= 0) { > > 76 for (int attempt = 0; attempt < > MAX_ATTEMPTS_NUMBER; attempt++) { > > 77 long memSwapUsage = > containerMetrics.getMemoryAndSwapUsage(); > > 78 long memUsage = > containerMetrics.getMemoryUsage(); > > 79 if (memSwapUsage > 0 && memUsage > 0) { > > 80 // We read "memory usage" and > "memory and swap usage" not atomically, > > 81 // and it's possible to get the > negative value when subtracting these two. > > 82 // If this happens just retry the > loop for a few iterations. > > 83 if ((memSwapUsage - memUsage) >= 0) > { > > 84 return memSwapLimit - memLimit > - (memSwapUsage - memUsage); > > 85 } > > 86 } > > 87 } > > 88 } > > 89 } > > 90 return getFreeSwapSpaceSize0(); > > 91 } > > ------------------------------------------------ > > If memSwapLimit (@line 73) equals memLimit (@line 74), then > getFreeSwapSpaceSize() may return a negative value @line 84. > > > > It would be better to fix it. > > Could you please review it and give me some advice? > > Would this be reproducible via a test? There is > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java > which > contains testOperatingSystemMXBeanAwareness() tests. > > It would be good to capture this in a test somehow. > > Thanks, > Severin > > > > From mandy.chung at oracle.com Thu Apr 16 16:45:27 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Apr 2020 09:45:27 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> Message-ID: <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> On 4/14/20 11:51 AM, Paul Sandoz wrote: > Looks good to me (not familiar with all the code areas. > > Minor suggestion: > > MethodHandles.java > > 1811 * ASCII periods. For the instance of {@link java.lang.Class} representing {@code C}: > 1812 *
    > 1813 *
  • {@link Class#getName()} returns the string {@code GN + "/" + }, > 1814 * even though this is not a valid binary class or interface name.
    • > 1815 *
  • {@link Class#descriptorString()} returns the string > 1816 * {@code "L" + N + ";" + "/" + }, > 1817 * even though this is not a valid type descriptor name.
    • > 1818 *
> > Add another bullet: > > ? > even though this is not a valid type descriptor name; and > > - therefore {@link Class#describeConstable} returns an empty {@code Optional}. > ? > > ? OK.?? I add this bullet: - Class.describeConstable() returns an empty optional as C cannot be described in nominal form. The webrev and spec was updated [1] for descriptor string to be of the form "Lfoo/Foo.1234;" to mitigate the compatibility risk.? Th Specdiff with serviceability spec change: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/ Specdiff without svc spec change: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-descriptor-string/overview-summary.html Webrev: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-descriptor-string/ Svc spec change webrev: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/ thanks Mandy [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007155.html > > Paul. > >> On Apr 11, 2020, at 8:13 PM, Mandy Chung wrote: >> >> Please review the delta patch: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/ >> >> Incremental specdiff: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html >> This is to follow a discussion [1] on Class::descriptorString and MethodType::descriptorString for hidden classes. The proposal is to define the descriptor string for a hidden class of this form: >> "L" + N + ";" + "/" + >> >> The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and `MethodType::descriptorString` are updated to return the descriptor of this form for a hidden class. To support hidden class, `java.lang.invoke.TypeDescriptor` spec is revised such that a `TypeDescriptor` object can represent an entity that may not be described in nominal form. This change affects JVM TI, JDWP and JDI. The spec change includes a couple other JVM TI and java.instrument spec clarification w.r.t. hidden classes that Serguei has been working on. >> >> >> >> Mandy >> [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html >> >> ---------------- >> As a record, the above patch is applied on the top: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06/ >> >> webrev.06 includes the following changes that have been reviewed: >> 1. rename "weak hidden" and Klass::is_hidden_weak to is_non_strong_hidden >> 2. remove unused `setImplMethod` method from lambda proxy class >> 3. include Serguei's patch to fix JDK-8242166: regression in JDI ClassUnload events >> 4. drop the uniqueness guarantee of the suffix of the hidden class's name >> >> On 3/31/20 8:01 PM, Mandy Chung wrote: >>> Thanks to the review feedbacks. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>> Delta between webrev.03 and webrev.04: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ >>> >>> Summary of changes is: >>> 1. Update javac to retain the previous behavior when compiling to target release <= 14 where lambda proxy class is not a nestmate >>> 2. Rename Class::isHiddenClass to Class::isHidden >>> 3. Address Joe's feedback on the CSR to document the behavior of the relevant methods in java.lang.Class for hidden classes >>> 4. Add test case for unloadable class with nest host error >>> 5. Add test cases for hidden classes with different kinds of class or interface >>> 6. Update dcmd to drop "weak hidden class" and refer it as "hidden class" >>> 7. Small changes in response to Remi, Coleen, Paul's review comments >>> 8. Fix copyright headers >>> 9. Fix @modules in tests >>> >>> Most of the changes above have also been reviewed as separate patches. >>> >>> Thanks >>> Mandy >>> >>> On 3/26/20 4:57 PM, Mandy Chung wrote: >>>> Please review the implementation of JEP 371: Hidden Classes. The main changes are in core-libs and hotspot runtime area. Small changes are made in javac, VM compiler (intrinsification of Class::isHiddenClass), JFR, JDI, and jcmd. CSR [1]has been reviewed and is in the finalized state (see specdiff and javadoc below for reference). >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >>>> >>>> javadoc/specdiff >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >>>> >>>> JVMS 5.4.4 change: >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >>>> >>>> CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8238359 >>>> >>>> Thanks >>>> Mandy >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.cheung at oracle.com Thu Apr 16 17:08:23 2020 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 16 Apr 2020 10:08:23 -0700 Subject: RFR[S] 8241158 SA TestHeapDumpForInvokeDynamic.java fails when CDS archive is relocated In-Reply-To: <706bd1c4-1741-8893-266b-8f135ec2767a@oracle.com> References: <53af11d5-830d-678c-7eb8-e97875c01770@oracle.com> <86ee56f9-7442-6eb2-2eea-6a93433d44f5@oracle.com> <706bd1c4-1741-8893-266b-8f135ec2767a@oracle.com> Message-ID: <7cbf6efa-b123-d34b-2032-265eb5651391@oracle.com> Hi Ioi, Regarding the changes in javaClasses.cpp, I saw that in your new code in systemDictionaryShared.cpp, the java_lang_Class::update_archived_mirror_native_pointers(m) won't be called if MetaspaceShared::relocation_delta() is 0. But I noticed there's another code path to java_lang_Class::update_archived_mirror_native_pointers() after HeapShared::fixup_mapped_heap_regions() is called in SystemDictionary::resolve_well_known_classes(): java_lang_Class::update_archived_mirror_native_pointers(oop) : void ??? java_lang_Class::restore_archived_mirror(Klass *, Handle, Handle, Handle, Thread *) : bool ??? ??? java_lang_Class::fixup_mirror(Klass *, Thread *) : void ??? ??? ??? Universe::fixup_mirrors(Thread *) : void SystemDictionary::resolve_well_known_classes(Thread *) : void ??? ??? ??? ??? ??? SystemDictionary::initialize(Thread *) : void ??? ??? ??? ??? ??? ??? Universe::genesis(Thread *) : void ??? ??? ??? ??? ??? ??? ??? universe2_init() : void ??? ??? ??? ??? ??? ??? ??? ??? init_globals() : ? Will MetaspaceShared::relocation_delta() always be non-zero in the above case? thanks, Calvin On 4/14/20 10:07 PM, Ioi Lam wrote: > Hi Chris, > > Thanks for the info. I've synced with the latest repo and updated the > webrev in-place: > > http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ > > I'll rerun tiers 1-4 as two of the affected tests > (ClhsdbDumpheap.java, TestHeapDumpForInvokeDynamic.java) will now be > executed on macos by mach5. > > Thanks > - Ioi > > On 4/14/20 3:34 PM, Chris Plummer wrote: >> [Not a review] >> >> Hi Ioi, >> >> Your ProblemList.txt is out of date. All those Solaris entries for >> 8193639 are now gone. >> >> thanks, >> >> Chris >> >> On 4/14/20 3:01 PM, Ioi Lam wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8241158 >>> http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ >>> >>> This is a bug in the CDS relocation code. When >>> -XX:ArchiveRelocationMode=1 is >>> specified, the CDS archive is mapped to an address picked by the OS >>> (instead of the default address 0x800000000). As a result, we need >>> to patch >>> the native Klass* pointers inside java.lang.Class instances that are >>> stored in the CDS archived heap region. >>> >>> Before this fix, the patching is done incrementally, when a class is >>> resolved. >>> However, when SA tries to do a heap dump, it may see a >>> java.lang.Class instance >>> that is not yet resolved, whose Klass* pointer has not been patched. >>> Dereferencing the unpatched pointer causes SA to fail. >>> >>> (The failure happens on macos only, probably because the invalid >>> dereference >>> causes different exceptions on other platforms due to specific >>> memory layout, >>> and SA is able to handle such exceptions and limp on). >>> >>> The fix is to unconditionally patch all the Klass* pointers during VM >>> initialization. >>> >>> We already patch a lot of stuff at start-up when the CDS archive is >>> relocated, >>> so doing a little patching more doesn't hurt. >>> >>> ---- >>> >>> Passed mach5 tiers 1-4. Ran the failed test manually on macos and it >>> passed. >>> >>> Thanks >>> - Ioi >> > From chris.plummer at oracle.com Thu Apr 16 17:18:15 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 16 Apr 2020 10:18:15 -0700 Subject: RFR(XS) 8242787: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with sun.jvm.hotspot.types.WrongTypeException Message-ID: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8242787 http://cr.openjdk.java.net/~cjplummer/8242787/webrev.00/index.html After fixing JDK-8230731 [1], this test still failed, this time with a WrongTypeException. The issue is basically the same one as was just fixed in JDK-8235220 [2]. With CDS on you sometimes get a WrongTypeException instead of an AddressException, so in some places code that allows an AddressException needs to also allow a WrongTypeException. Note that fixing this issue then exposes JDK-8242789 [3], which I'll be fixing next, so the problem list entry changed from JDK-8242787 to JDK-8242789. I also did a bit of cleaning up of some debugging code. During my debugging session I set DEBUG = true to get some extra debugging output, and suddenly a lot of tests were failing with a RuntimeException. This is because of the debugging code I've now stripped out. It decided to convert an acceptable failure type (UnknownOopException) into one that the outer try/catch would not catch (RuntimeException). UnknownOopException is not suppose to cause iterateLiveRegions() to abort. https://bugs.openjdk.java.net/browse/JDK-8230731 https://bugs.openjdk.java.net/browse/JDK-8235220 https://bugs.openjdk.java.net/browse/JDK-8242789 thanks, Chris From ioi.lam at oracle.com Thu Apr 16 18:12:00 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 16 Apr 2020 11:12:00 -0700 Subject: RFR[S] 8241158 SA TestHeapDumpForInvokeDynamic.java fails when CDS archive is relocated In-Reply-To: <7cbf6efa-b123-d34b-2032-265eb5651391@oracle.com> References: <53af11d5-830d-678c-7eb8-e97875c01770@oracle.com> <86ee56f9-7442-6eb2-2eea-6a93433d44f5@oracle.com> <706bd1c4-1741-8893-266b-8f135ec2767a@oracle.com> <7cbf6efa-b123-d34b-2032-265eb5651391@oracle.com> Message-ID: On 4/16/20 10:08 AM, Calvin Cheung wrote: > Hi Ioi, > > Regarding the changes in javaClasses.cpp, I saw that in your new code > in systemDictionaryShared.cpp, the > java_lang_Class::update_archived_mirror_native_pointers(m) won't be > called if MetaspaceShared::relocation_delta() is 0. But I noticed > there's another code path to > java_lang_Class::update_archived_mirror_native_pointers() after > HeapShared::fixup_mapped_heap_regions() is called in > SystemDictionary::resolve_well_known_classes(): > > java_lang_Class::update_archived_mirror_native_pointers(oop) : void > ??? java_lang_Class::restore_archived_mirror(Klass *, Handle, Handle, > Handle, Thread *) : bool > ??? ??? java_lang_Class::fixup_mirror(Klass *, Thread *) : void > ??? ??? ??? Universe::fixup_mirrors(Thread *) : void > SystemDictionary::resolve_well_known_classes(Thread *) : void > ??? ??? ??? ??? ??? SystemDictionary::initialize(Thread *) : void > ??? ??? ??? ??? ??? ??? Universe::genesis(Thread *) : void > ??? ??? ??? ??? ??? ??? ??? universe2_init() : void > ??? ??? ??? ??? ??? ??? ??? ??? init_globals() : ? > > Will MetaspaceShared::relocation_delta() always be non-zero in the > above case? > Hi Calvin, Thanks for taking a look at this. As part of this patch, the call path that you mentioned above has been removed. Now we always call update_archived_mirror_native_pointers on all archived classes at VM start-up, so there's no need to patch individual mirrors during class loading. See the change on line 1294. http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/src/hotspot/share/classfile/javaClasses.cpp.cdiff.html Thanks - Ioi > thanks, > > Calvin > > On 4/14/20 10:07 PM, Ioi Lam wrote: >> Hi Chris, >> >> Thanks for the info. I've synced with the latest repo and updated the >> webrev in-place: >> >> http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ >> >> I'll rerun tiers 1-4 as two of the affected tests >> (ClhsdbDumpheap.java, TestHeapDumpForInvokeDynamic.java) will now be >> executed on macos by mach5. >> >> Thanks >> - Ioi >> >> On 4/14/20 3:34 PM, Chris Plummer wrote: >>> [Not a review] >>> >>> Hi Ioi, >>> >>> Your ProblemList.txt is out of date. All those Solaris entries for >>> 8193639 are now gone. >>> >>> thanks, >>> >>> Chris >>> >>> On 4/14/20 3:01 PM, Ioi Lam wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8241158 >>>> http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ >>>> >>>> >>>> This is a bug in the CDS relocation code. When >>>> -XX:ArchiveRelocationMode=1 is >>>> specified, the CDS archive is mapped to an address picked by the OS >>>> (instead of the default address 0x800000000). As a result, we need >>>> to patch >>>> the native Klass* pointers inside java.lang.Class instances that are >>>> stored in the CDS archived heap region. >>>> >>>> Before this fix, the patching is done incrementally, when a class >>>> is resolved. >>>> However, when SA tries to do a heap dump, it may see a >>>> java.lang.Class instance >>>> that is not yet resolved, whose Klass* pointer has not been patched. >>>> Dereferencing the unpatched pointer causes SA to fail. >>>> >>>> (The failure happens on macos only, probably because the invalid >>>> dereference >>>> causes different exceptions on other platforms due to specific >>>> memory layout, >>>> and SA is able to handle such exceptions and limp on). >>>> >>>> The fix is to unconditionally patch all the Klass* pointers during VM >>>> initialization. >>>> >>>> We already patch a lot of stuff at start-up when the CDS archive is >>>> relocated, >>>> so doing a little patching more doesn't hurt. >>>> >>>> ---- >>>> >>>> Passed mach5 tiers 1-4. Ran the failed test manually on macos and >>>> it passed. >>>> >>>> Thanks >>>> - Ioi >>> >> From serguei.spitsyn at oracle.com Thu Apr 16 18:42:29 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Apr 2020 11:42:29 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> Message-ID: <330b7f12-4357-5f2f-7fa3-7896a1c3415e@oracle.com> An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Apr 16 18:48:41 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Apr 2020 11:48:41 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <330b7f12-4357-5f2f-7fa3-7896a1c3415e@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <330b7f12-4357-5f2f-7fa3-7896a1c3415e@oracle.com> Message-ID: On 4/16/20 11:42 AM, serguei.spitsyn at oracle.com wrote: > Hi Mandy, > > I have a couple of minor comments on the Serviceability spec update. > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java.udiff.html > > ?Replace: "The returned name is the same form as ..." => "The returned > name is of the same form as ..." > > > Example is: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/src/jdk.jdi/share/classes/com/sun/jdi/Type.java.udiff.html > > ? + * Returns the name of this type. The result is of the same form as > > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java.udiff.html > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java.udiff.html > > Both files above have this: "a `class` file representation". > It feels like something is wrong with the `class` part. > Should it say `class file` or maybe use some other formatting? > > Otherwise, the Serviceability spec update looks great. > I'll look at the non-Serviceability spec changes too. Thanks for catching these typo/format issue.? I have fixed them in my local repo: diff --git a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java --- a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java +++ b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java @@ -391,7 +391,7 @@ ????? *

????? * A class or interface creation can be triggered by one of the following: ????? *

    -???? *
  • by loading and deriving a class from a `class` file representation +???? *
  • by loading and deriving a class from a {@code class} file representation ????? *???? using class loader (see JVMS {@jvms 5.3}). ????? *
  • by invoking {@link java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) ????? *???? Lookup::defineHiddenClass} that creates a {@link Class#isHidden diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java b/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java --- a/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java @@ -85,7 +85,7 @@ ?{ ???? /** ????? * Returns the name of this {@code ReferenceType} object. -???? * The returned name is the same form as the name returned by +???? * The returned name is of the same form as the name returned by ????? * {@link Class#getName()}. ????? * ????? * @return a string containing the type name. diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java @@ -137,7 +137,7 @@ ????? *

    ????? * A class or interface creation can be triggered by one of the following: ????? *

      -???? *
    • by loading and deriving a class from a `class` file representation +???? *
    • by loading and deriving a class from a {@code class} file representation ????? *???? using class loader (see JVMS {@jvms 5.3}). ????? *
    • by invoking {@link java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) ????? *???? Lookup::defineHiddenClass} that creates a {@link Class#isHidden Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.cheung at oracle.com Thu Apr 16 18:55:34 2020 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 16 Apr 2020 11:55:34 -0700 Subject: RFR[S] 8241158 SA TestHeapDumpForInvokeDynamic.java fails when CDS archive is relocated In-Reply-To: References: <53af11d5-830d-678c-7eb8-e97875c01770@oracle.com> <86ee56f9-7442-6eb2-2eea-6a93433d44f5@oracle.com> <706bd1c4-1741-8893-266b-8f135ec2767a@oracle.com> <7cbf6efa-b123-d34b-2032-265eb5651391@oracle.com> Message-ID: On 4/16/20 11:12 AM, Ioi Lam wrote: > On 4/16/20 10:08 AM, Calvin Cheung wrote: >> Hi Ioi, >> >> Regarding the changes in javaClasses.cpp, I saw that in your new code >> in systemDictionaryShared.cpp, the >> java_lang_Class::update_archived_mirror_native_pointers(m) won't be >> called if MetaspaceShared::relocation_delta() is 0. But I noticed >> there's another code path to >> java_lang_Class::update_archived_mirror_native_pointers() after >> HeapShared::fixup_mapped_heap_regions() is called in >> SystemDictionary::resolve_well_known_classes(): >> >> java_lang_Class::update_archived_mirror_native_pointers(oop) : void >> ??? java_lang_Class::restore_archived_mirror(Klass *, Handle, Handle, >> Handle, Thread *) : bool >> ??? ??? java_lang_Class::fixup_mirror(Klass *, Thread *) : void >> ??? ??? ??? Universe::fixup_mirrors(Thread *) : void >> SystemDictionary::resolve_well_known_classes(Thread *) : void >> ??? ??? ??? ??? ??? SystemDictionary::initialize(Thread *) : void >> ??? ??? ??? ??? ??? ??? Universe::genesis(Thread *) : void >> ??? ??? ??? ??? ??? ??? ??? universe2_init() : void >> ??? ??? ??? ??? ??? ??? ??? ??? init_globals() : ? >> >> Will MetaspaceShared::relocation_delta() always be non-zero in the >> above case? >> > Hi Calvin, > > Thanks for taking a look at this. > > As part of this patch, the call path that you mentioned above has been > removed. Now we always call update_archived_mirror_native_pointers on > all archived classes at VM start-up, so there's no need to patch > individual mirrors during class loading. > > See the change on line 1294. > > http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/src/hotspot/share/classfile/javaClasses.cpp.cdiff.html > I see. The proposed change looks good. thanks, Calvin > > Thanks > - Ioi > > > > >> thanks, >> >> Calvin >> >> On 4/14/20 10:07 PM, Ioi Lam wrote: >>> Hi Chris, >>> >>> Thanks for the info. I've synced with the latest repo and updated >>> the webrev in-place: >>> >>> http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ >>> >>> I'll rerun tiers 1-4 as two of the affected tests >>> (ClhsdbDumpheap.java, TestHeapDumpForInvokeDynamic.java) will now be >>> executed on macos by mach5. >>> >>> Thanks >>> - Ioi >>> >>> On 4/14/20 3:34 PM, Chris Plummer wrote: >>>> [Not a review] >>>> >>>> Hi Ioi, >>>> >>>> Your ProblemList.txt is out of date. All those Solaris entries for >>>> 8193639 are now gone. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 4/14/20 3:01 PM, Ioi Lam wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8241158 >>>>> http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ >>>>> >>>>> >>>>> This is a bug in the CDS relocation code. When >>>>> -XX:ArchiveRelocationMode=1 is >>>>> specified, the CDS archive is mapped to an address picked by the OS >>>>> (instead of the default address 0x800000000). As a result, we need >>>>> to patch >>>>> the native Klass* pointers inside java.lang.Class instances that are >>>>> stored in the CDS archived heap region. >>>>> >>>>> Before this fix, the patching is done incrementally, when a class >>>>> is resolved. >>>>> However, when SA tries to do a heap dump, it may see a >>>>> java.lang.Class instance >>>>> that is not yet resolved, whose Klass* pointer has not been patched. >>>>> Dereferencing the unpatched pointer causes SA to fail. >>>>> >>>>> (The failure happens on macos only, probably because the invalid >>>>> dereference >>>>> causes different exceptions on other platforms due to specific >>>>> memory layout, >>>>> and SA is able to handle such exceptions and limp on). >>>>> >>>>> The fix is to unconditionally patch all the Klass* pointers during VM >>>>> initialization. >>>>> >>>>> We already patch a lot of stuff at start-up when the CDS archive >>>>> is relocated, >>>>> so doing a little patching more doesn't hurt. >>>>> >>>>> ---- >>>>> >>>>> Passed mach5 tiers 1-4. Ran the failed test manually on macos and >>>>> it passed. >>>>> >>>>> Thanks >>>>> - Ioi >>>> >>> > From serguei.spitsyn at oracle.com Thu Apr 16 20:13:23 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Apr 2020 13:13:23 -0700 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> Message-ID: <056ba00d-4e1e-f48e-6d7e-10d026b0d2a6@oracle.com> Hi Yasumasa, Thank you for the update. It looks good. Thanks, Serguei On 4/10/20 04:30, Yasumasa Suenaga wrote: > Hi Serguei, > > I use current_jt in this webrev. Could you review again? > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ > > I tested this change with vmTestbase/nsk/jvmti, they are fine on my > Linux x64. > > > Thanks, > > Yasumasa > > > On 2020/04/10 17:21, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> Thank you for the update. >> >> Minor: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/src/hotspot/share/prims/jvmtiEnvBase.cpp.udiff.html >> >> >> + err = get_locked_objects_in_frame(JavaThread::current(), >> java_thread, jvf, owned_monitors_list, depth-1); . . . >> >> + JvmtiMonitorClosure jmc(java_thread, JavaThread::current(), >> owned_monitors_list, this); >> >> You can use current_jt instead of JavaThread::current() above. >> >> There is also some test coverage in the >> vmTestbase/nsk/jvmti/scenarios tests. >> This one as well: >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest >> >> Probably it is easier to run all vmTestbase/nsk/jvmti tests. >> >> Thanks, >> Serguei >> >> >> On 4/10/20 01:05, Yasumasa Suenaga wrote: >>> Hi Serguei, >>> >>> Thanks for your comment! >>> I uploaded new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/ >>> >>> I ran following tests, and all of them were passed on my Linux x64. >>> >>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>> ?- vmTestbase/nsk/jdi >>> ?- vmTestbase/nsk/jdwp >>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>> ?- serviceability/jdwp >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/04/10 14:50, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> It looks pretty good in general. >>>> A couple of comments though. >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html >>>> >>>> >>>> 650 JvmtiEnvBase::get_current_contended_monitor(JavaThread >>>> *java_thread, jobject *monitor_ptr) { >>>> 651 assert(!Thread::current()->is_VM_thread() && >>>> 652 (Thread::current() == java_thread || >>>> 653 Thread::current() == java_thread->active_handshaker()), >>>> 654 "call by myself or at direct handshake"); >>>> >>>> ? ... >>>> >>>> 685 JvmtiEnvBase::get_owned_monitors(JavaThread* java_thread, >>>> ? 686 GrowableArray >>>> *owned_monitors_list) { >>>> ? 687?? jvmtiError err = JVMTI_ERROR_NONE; >>>> 688 assert(!Thread::current()->is_VM_thread() && >>>> 689 (Thread::current() == java_thread || >>>> 690 Thread::current() == java_thread->active_handshaker()), >>>> 691 "call by myself or at direct handshake"); >>>> >>>> I'd suggest to add this at the beginning: >>>> ?? JavaThread *current_jt = JavaThread::current(); >>>> >>>> >>>> 676 JavaThread *current_jt = reinterpret_cast>>> *>(JavaThread::current()); >>>> >>>> There is not need in reinterpret_cast. Also, you can >>>> use the current_jt defined above. >>>> >>>> Also, please, removed these two definitions as they became unused >>>> with your fix: >>>> ??? src/hotspot/share/runtime/vmOperations.hpp: >>>> template(GGetCurrentContendedMonitoretOwnedMonitorInfo) \ >>>> ??? src/hotspot/share/runtime/vmOperations.hpp: >>>> template()??????????? \ >>>> >>>> The impacted JVMTI monitor functions are used in the JDWP agent to >>>> support the JDI ThreadReference implementation. >>>> To be safe the JDI & JDWP tests have to be run as well. It is well >>>> covered by the tier-5. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/9/20 21:46, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/ >>>>> >>>>> We've discussed to use Thread-Local Handshake in some JVMTI >>>>> functions [1]. >>>>> This change is for monitor functions. It affects >>>>> GetOwnedMonitorInfo(), GetOwnedMonitorStackDepthInfo(), >>>>> GetCurrentContendedMonitor(). >>>>> >>>>> It passed tests on submit repo >>>>> (mach5-one-ysuenaga-JDK-8242425-20200410-0228-10075639), and also >>>>> I confirmed to pass following tests: >>>>> >>>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html >>>> >> From alexey.menkov at oracle.com Thu Apr 16 20:37:09 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 16 Apr 2020 13:37:09 -0700 Subject: RFR(XS) 8242787: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with sun.jvm.hotspot.types.WrongTypeException In-Reply-To: References: Message-ID: <5812fdc5-7f78-ce75-0de1-f41cfbabb682@oracle.com> Hi Chris, The fix looks good to me. --alex On 04/16/2020 10:18, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242787 > http://cr.openjdk.java.net/~cjplummer/8242787/webrev.00/index.html > > After fixing JDK-8230731 [1], this test still failed, this time with a > WrongTypeException. The issue is basically the same one as was just > fixed in JDK-8235220 [2]. With CDS on you sometimes get a > WrongTypeException instead of an AddressException, so in some places > code that allows an AddressException needs to also allow a > WrongTypeException. > > Note that fixing this issue then exposes JDK-8242789 [3], which I'll be > fixing next, so the problem list entry changed from JDK-8242787 to > JDK-8242789. > > I also did a bit of cleaning up of some debugging code. During my > debugging session I set DEBUG = true to get some extra debugging output, > and suddenly a lot of tests were failing with a RuntimeException. This > is because of the debugging code I've now stripped out. It decided to > convert an acceptable failure type (UnknownOopException) into one that > the outer try/catch would not catch (RuntimeException). > UnknownOopException is not suppose to cause iterateLiveRegions() to abort. > > https://bugs.openjdk.java.net/browse/JDK-8230731 > https://bugs.openjdk.java.net/browse/JDK-8235220 > https://bugs.openjdk.java.net/browse/JDK-8242789 > > thanks, > > Chris From ioi.lam at oracle.com Thu Apr 16 20:53:33 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 16 Apr 2020 13:53:33 -0700 Subject: RFR[S] 8241158 SA TestHeapDumpForInvokeDynamic.java fails when CDS archive is relocated In-Reply-To: References: <53af11d5-830d-678c-7eb8-e97875c01770@oracle.com> <86ee56f9-7442-6eb2-2eea-6a93433d44f5@oracle.com> <706bd1c4-1741-8893-266b-8f135ec2767a@oracle.com> <7cbf6efa-b123-d34b-2032-265eb5651391@oracle.com> Message-ID: On 4/16/20 11:55 AM, Calvin Cheung wrote: > > On 4/16/20 11:12 AM, Ioi Lam wrote: >> On 4/16/20 10:08 AM, Calvin Cheung wrote: >>> Hi Ioi, >>> >>> Regarding the changes in javaClasses.cpp, I saw that in your new >>> code in systemDictionaryShared.cpp, the >>> java_lang_Class::update_archived_mirror_native_pointers(m) won't be >>> called if MetaspaceShared::relocation_delta() is 0. But I noticed >>> there's another code path to >>> java_lang_Class::update_archived_mirror_native_pointers() after >>> HeapShared::fixup_mapped_heap_regions() is called in >>> SystemDictionary::resolve_well_known_classes(): >>> >>> java_lang_Class::update_archived_mirror_native_pointers(oop) : void >>> ??? java_lang_Class::restore_archived_mirror(Klass *, Handle, >>> Handle, Handle, Thread *) : bool >>> ??? ??? java_lang_Class::fixup_mirror(Klass *, Thread *) : void >>> ??? ??? ??? Universe::fixup_mirrors(Thread *) : void >>> SystemDictionary::resolve_well_known_classes(Thread *) : void >>> ??? ??? ??? ??? ??? SystemDictionary::initialize(Thread *) : void >>> ??? ??? ??? ??? ??? ??? Universe::genesis(Thread *) : void >>> ??? ??? ??? ??? ??? ??? ??? universe2_init() : void >>> ??? ??? ??? ??? ??? ??? ??? ??? init_globals() : ? >>> >>> Will MetaspaceShared::relocation_delta() always be non-zero in the >>> above case? >>> >> Hi Calvin, >> >> Thanks for taking a look at this. >> >> As part of this patch, the call path that you mentioned above has >> been removed. Now we always call >> update_archived_mirror_native_pointers on all archived classes at VM >> start-up, so there's no need to patch individual mirrors during class >> loading. >> >> See the change on line 1294. >> >> http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/src/hotspot/share/classfile/javaClasses.cpp.cdiff.html >> > > I see. The proposed change looks good. > Thanks Calvin! - Ioi > thanks, > Calvin >> >> Thanks >> - Ioi >> >> >> >> >>> thanks, >>> >>> Calvin >>> >>> On 4/14/20 10:07 PM, Ioi Lam wrote: >>>> Hi Chris, >>>> >>>> Thanks for the info. I've synced with the latest repo and updated >>>> the webrev in-place: >>>> >>>> http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ >>>> >>>> >>>> I'll rerun tiers 1-4 as two of the affected tests >>>> (ClhsdbDumpheap.java, TestHeapDumpForInvokeDynamic.java) will now >>>> be executed on macos by mach5. >>>> >>>> Thanks >>>> - Ioi >>>> >>>> On 4/14/20 3:34 PM, Chris Plummer wrote: >>>>> [Not a review] >>>>> >>>>> Hi Ioi, >>>>> >>>>> Your ProblemList.txt is out of date. All those Solaris entries for >>>>> 8193639 are now gone. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 4/14/20 3:01 PM, Ioi Lam wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8241158 >>>>>> http://cr.openjdk.java.net/~iklam/jdk15/8241158-sa-heap-dump-fails.v01/ >>>>>> >>>>>> >>>>>> This is a bug in the CDS relocation code. When >>>>>> -XX:ArchiveRelocationMode=1 is >>>>>> specified, the CDS archive is mapped to an address picked by the OS >>>>>> (instead of the default address 0x800000000). As a result, we >>>>>> need to patch >>>>>> the native Klass* pointers inside java.lang.Class instances that are >>>>>> stored in the CDS archived heap region. >>>>>> >>>>>> Before this fix, the patching is done incrementally, when a class >>>>>> is resolved. >>>>>> However, when SA tries to do a heap dump, it may see a >>>>>> java.lang.Class instance >>>>>> that is not yet resolved, whose Klass* pointer has not been patched. >>>>>> Dereferencing the unpatched pointer causes SA to fail. >>>>>> >>>>>> (The failure happens on macos only, probably because the invalid >>>>>> dereference >>>>>> causes different exceptions on other platforms due to specific >>>>>> memory layout, >>>>>> and SA is able to handle such exceptions and limp on). >>>>>> >>>>>> The fix is to unconditionally patch all the Klass* pointers >>>>>> during VM >>>>>> initialization. >>>>>> >>>>>> We already patch a lot of stuff at start-up when the CDS archive >>>>>> is relocated, >>>>>> so doing a little patching more doesn't hurt. >>>>>> >>>>>> ---- >>>>>> >>>>>> Passed mach5 tiers 1-4. Ran the failed test manually on macos and >>>>>> it passed. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>> >>>> >> From ioi.lam at oracle.com Thu Apr 16 20:54:47 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 16 Apr 2020 13:54:47 -0700 Subject: RFR(XS) 8242787: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with sun.jvm.hotspot.types.WrongTypeException In-Reply-To: References: Message-ID: <86c1fcd5-5873-cd44-faff-356c7b5a2150@oracle.com> Hi Chris, This change looks good to me. Thanks - Ioi On 4/16/20 10:18 AM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242787 > http://cr.openjdk.java.net/~cjplummer/8242787/webrev.00/index.html > > After fixing JDK-8230731 [1], this test still failed, this time with a > WrongTypeException. The issue is basically the same one as was just > fixed in JDK-8235220 [2]. With CDS on you sometimes get a > WrongTypeException instead of an AddressException, so in some places > code that allows an AddressException needs to also allow a > WrongTypeException. > > Note that fixing this issue then exposes JDK-8242789 [3], which I'll > be fixing next, so the problem list entry changed from JDK-8242787 to > JDK-8242789. > > I also did a bit of cleaning up of some debugging code. During my > debugging session I set DEBUG = true to get some extra debugging > output, and suddenly a lot of tests were failing with a > RuntimeException. This is because of the debugging code I've now > stripped out. It decided to convert an acceptable failure type > (UnknownOopException) into one that the outer try/catch would not > catch (RuntimeException). UnknownOopException is not suppose to cause > iterateLiveRegions() to abort. > > https://bugs.openjdk.java.net/browse/JDK-8230731 > https://bugs.openjdk.java.net/browse/JDK-8235220 > https://bugs.openjdk.java.net/browse/JDK-8242789 > > thanks, > > Chris From serguei.spitsyn at oracle.com Thu Apr 16 21:55:20 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Apr 2020 14:55:20 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <330b7f12-4357-5f2f-7fa3-7896a1c3415e@oracle.com> Message-ID: <8a538e39-01aa-b896-60d2-a812b90ca08d@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Apr 16 21:59:50 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Apr 2020 14:59:50 -0700 Subject: RFR(XS) 8242787: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with sun.jvm.hotspot.types.WrongTypeException In-Reply-To: References: Message-ID: <68945644-4102-8f00-c507-2885b6a4d5aa@oracle.com> Hi Chris, This looks good. Thanks, Serguei On 4/16/20 10:18, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242787 > http://cr.openjdk.java.net/~cjplummer/8242787/webrev.00/index.html > > After fixing JDK-8230731 [1], this test still failed, this time with a > WrongTypeException. The issue is basically the same one as was just > fixed in JDK-8235220 [2]. With CDS on you sometimes get a > WrongTypeException instead of an AddressException, so in some places > code that allows an AddressException needs to also allow a > WrongTypeException. > > Note that fixing this issue then exposes JDK-8242789 [3], which I'll > be fixing next, so the problem list entry changed from JDK-8242787 to > JDK-8242789. > > I also did a bit of cleaning up of some debugging code. During my > debugging session I set DEBUG = true to get some extra debugging > output, and suddenly a lot of tests were failing with a > RuntimeException. This is because of the debugging code I've now > stripped out. It decided to convert an acceptable failure type > (UnknownOopException) into one that the outer try/catch would not > catch (RuntimeException). UnknownOopException is not suppose to cause > iterateLiveRegions() to abort. > > https://bugs.openjdk.java.net/browse/JDK-8230731 > https://bugs.openjdk.java.net/browse/JDK-8235220 > https://bugs.openjdk.java.net/browse/JDK-8242789 > > thanks, > > Chris From suenaga at oss.nttdata.com Thu Apr 16 23:53:21 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 17 Apr 2020 08:53:21 +0900 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: <056ba00d-4e1e-f48e-6d7e-10d026b0d2a6@oracle.com> References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> <056ba00d-4e1e-f48e-6d7e-10d026b0d2a6@oracle.com> Message-ID: <1fd7bf53-179c-9887-505a-cc44088a6568@oss.nttdata.com> Thanks Serguei! Yasumasa On 2020/04/17 5:13, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > Thank you for the update. > It looks good. > > Thanks, > Serguei > > > On 4/10/20 04:30, Yasumasa Suenaga wrote: >> Hi Serguei, >> >> I use current_jt in this webrev. Could you review again? >> >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ >> >> I tested this change with vmTestbase/nsk/jvmti, they are fine on my Linux x64. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/10 17:21, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> Thank you for the update. >>> >>> Minor: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/src/hotspot/share/prims/jvmtiEnvBase.cpp.udiff.html >>> >>> + err = get_locked_objects_in_frame(JavaThread::current(), java_thread, jvf, owned_monitors_list, depth-1); . . . >>> >>> + JvmtiMonitorClosure jmc(java_thread, JavaThread::current(), owned_monitors_list, this); >>> >>> You can use current_jt instead of JavaThread::current() above. >>> >>> There is also some test coverage in the vmTestbase/nsk/jvmti/scenarios tests. >>> This one as well: >>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest >>> Probably it is easier to run all vmTestbase/nsk/jvmti tests. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/10/20 01:05, Yasumasa Suenaga wrote: >>>> Hi Serguei, >>>> >>>> Thanks for your comment! >>>> I uploaded new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/ >>>> >>>> I ran following tests, and all of them were passed on my Linux x64. >>>> >>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>> ?- vmTestbase/nsk/jdi >>>> ?- vmTestbase/nsk/jdwp >>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>> ?- serviceability/jdwp >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/04/10 14:50, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa, >>>>> >>>>> It looks pretty good in general. >>>>> A couple of comments though. >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html >>>>> >>>>> 650 JvmtiEnvBase::get_current_contended_monitor(JavaThread *java_thread, jobject *monitor_ptr) { >>>>> 651 assert(!Thread::current()->is_VM_thread() && >>>>> 652 (Thread::current() == java_thread || >>>>> 653 Thread::current() == java_thread->active_handshaker()), >>>>> 654 "call by myself or at direct handshake"); >>>>> >>>>> ? ... >>>>> >>>>> 685 JvmtiEnvBase::get_owned_monitors(JavaThread* java_thread, >>>>> ? 686 GrowableArray *owned_monitors_list) { >>>>> ? 687?? jvmtiError err = JVMTI_ERROR_NONE; >>>>> 688 assert(!Thread::current()->is_VM_thread() && >>>>> 689 (Thread::current() == java_thread || >>>>> 690 Thread::current() == java_thread->active_handshaker()), >>>>> 691 "call by myself or at direct handshake"); >>>>> >>>>> I'd suggest to add this at the beginning: >>>>> ?? JavaThread *current_jt = JavaThread::current(); >>>>> >>>>> >>>>> 676 JavaThread *current_jt = reinterpret_cast(JavaThread::current()); >>>>> >>>>> There is not need in reinterpret_cast. Also, you can use the current_jt defined above. >>>>> >>>>> Also, please, removed these two definitions as they became unused with your fix: >>>>> ??? src/hotspot/share/runtime/vmOperations.hpp: template(GGetCurrentContendedMonitoretOwnedMonitorInfo) \ >>>>> ??? src/hotspot/share/runtime/vmOperations.hpp: template()??????????? \ >>>>> >>>>> The impacted JVMTI monitor functions are used in the JDWP agent to support the JDI ThreadReference implementation. >>>>> To be safe the JDI & JDWP tests have to be run as well. It is well covered by the tier-5. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 4/9/20 21:46, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this change: >>>>>> >>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >>>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/ >>>>>> >>>>>> We've discussed to use Thread-Local Handshake in some JVMTI functions [1]. >>>>>> This change is for monitor functions. It affects GetOwnedMonitorInfo(), GetOwnedMonitorStackDepthInfo(), GetCurrentContendedMonitor(). >>>>>> >>>>>> It passed tests on submit repo (mach5-one-ysuenaga-JDK-8242425-20200410-0228-10075639), and also I confirmed to pass following tests: >>>>>> >>>>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html >>>>> >>> > From david.holmes at oracle.com Fri Apr 17 01:47:54 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Apr 2020 11:47:54 +1000 Subject: RFR (T) 8242896: typo #ifdef INCLUDE_JVMTI in codeCache.cpp In-Reply-To: References: <048f98a3-4c8c-f691-6aa1-44d72b3020f3@oracle.com> Message-ID: <4c5b7921-632a-fa35-402b-4f322d4af450@oracle.com> Hi Coleen, Still LGTM. The other guarded methods are only called from JVMTI code. The two that are now stubbed out would have been no-ops without JVMTI as old_compiled_method_table would have been NULL. Still seems trivial to me. Thanks, David On 17/04/2020 1:14 am, coleen.phillimore at oracle.com wrote: > > > On 4/16/20 10:24 AM, Magnus Ihse Bursie wrote: >> On 2020-04-16 04:37, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 4/15/20 9:37 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 16/04/2020 10:59 am, coleen.phillimore at oracle.com wrote: >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8242896.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8242896 >>>> >>>> Looks good but ... >>>> >>>>> Built and ran vmTestbase RedefineTests which use the protected code. >>>> >>>> ... you need to ensure that builds that don't INCLUDE_JVMTI still >>>> work okay as they will now actually be excluding this code for the >>>> first time. >>> >>> Last time I tried to build minimal, it failed for some odd problem on >>> my system.? I'll wait until someone from the openjdk can build it then. >>> thanks, >> Building minimal should work.? Try something like this: "jib configure >> -- --with-jvm-variants=minimal". It should work. > > I used to get some error about some X11 library.? I don't remember what > it was.? Now I get this warning: > > The following warnings were produced. Repeated here for convenience: > WARNING: Ignoring value of PERL from the environment. Use command line > variables instead. > > I'm not sure what it means but it seems to be building. > >> >> I just tried with your patch, and it does not work. >> >> /localhome/hg/jdk-BAR/open/src/hotspot/share/classfile/metadataOnStackMark.cpp:70: >> error: undefined reference to >> 'CodeCache::old_nmethods_do(MetadataClosure*)' >> /localhome/hg/jdk-BAR/open/src/hotspot/share/code/nmethod.cpp:1495: >> error: undefined reference to >> 'CodeCache::unregister_old_nmethod(CompiledMethod*)' >> >> I made a quick check but it was not clear to me if the call sites in >> metadataOnStackMark.cpp and nmethod.cpp should be excluded if missing >> jvmti, or if the code in codeCache.cpp should really be present even >> with jvmti. > > They should be excluded. Thanks for testing it for me.? Now it builds > (up to that point).? Hopefully still trivial. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8242896.02/webrev > > Thanks! > Coleen >> >> /Magnus >> >> >>> Coleen >>>> >>>> Thanks, >>>> David >>>> >>>>> thanks, >>>>> Coleen >>> >> > From david.holmes at oracle.com Fri Apr 17 03:58:44 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Apr 2020 13:58:44 +1000 Subject: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker(Internet mail) In-Reply-To: <7EABDE84-236C-44B9-8599-C7131456131F@tencent.com> References: <7EABDE84-236C-44B9-8599-C7131456131F@tencent.com> Message-ID: <610ae571-58dd-c7d5-d089-9c18acc18a75@oracle.com> Hi Jie, On 16/04/2020 11:23 pm, jiefu(??) wrote: > Hi Severin, > > Thanks for your review and very nice suggestions. > > Updated: http://cr.openjdk.java.net/~jiefu/8242480/webrev.01/ > > test/hotspot/jtreg/containers/docker/TestGetFreeSwapSpaceSize.java is added to reproduce the bug. Can you please use the standard OpenJDK file header after your Tencent copyright line: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ I don't think the "classpath exception" is relevant to tests - certainly other tests I checked do not have it. Thanks, David ----- > Thanks a lot. > Best regards, > Jie > > > ?On 2020/4/16, 4:40 PM, "Severin Gehwolf" wrote: > > Hi Jie, > > On Fri, 2020-04-10 at 01:49 +0000, jiefu(??) wrote: > > Hi all, > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242480 > > Webrev: http://cr.openjdk.java.net/~jiefu/8242480/webrev.00/ > > > > Negative values were returned by getFreeSwapSpaceSize() in our docker testing. > > The reason is that current implementation doesn't consider the situation when memory.limit_in_bytes == memory.memsw.limit_in_bytes, which means do not use the swap space at all. > > > > In src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java, let's see > > ------------------------------------------------ > > 71 public long getFreeSwapSpaceSize() { > > 72 if (containerMetrics != null) { > > 73 long memSwapLimit = containerMetrics.getMemoryAndSwapLimit(); > > 74 long memLimit = containerMetrics.getMemoryLimit(); > > 75 if (memSwapLimit >= 0 && memLimit >= 0) { > > 76 for (int attempt = 0; attempt < MAX_ATTEMPTS_NUMBER; attempt++) { > > 77 long memSwapUsage = containerMetrics.getMemoryAndSwapUsage(); > > 78 long memUsage = containerMetrics.getMemoryUsage(); > > 79 if (memSwapUsage > 0 && memUsage > 0) { > > 80 // We read "memory usage" and "memory and swap usage" not atomically, > > 81 // and it's possible to get the negative value when subtracting these two. > > 82 // If this happens just retry the loop for a few iterations. > > 83 if ((memSwapUsage - memUsage) >= 0) { > > 84 return memSwapLimit - memLimit - (memSwapUsage - memUsage); > > 85 } > > 86 } > > 87 } > > 88 } > > 89 } > > 90 return getFreeSwapSpaceSize0(); > > 91 } > > ------------------------------------------------ > > If memSwapLimit (@line 73) equals memLimit (@line 74), then getFreeSwapSpaceSize() may return a negative value @line 84. > > > > It would be better to fix it. > > Could you please review it and give me some advice? > > Would this be reproducible via a test? There is > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java which > contains testOperatingSystemMXBeanAwareness() tests. > > It would be good to capture this in a test somehow. > > Thanks, > Severin > > > > From david.holmes at oracle.com Fri Apr 17 04:17:02 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Apr 2020 14:17:02 +1000 Subject: RFR(XS) 8242787: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with sun.jvm.hotspot.types.WrongTypeException In-Reply-To: References: Message-ID: Hi Chris, On 17/04/2020 3:18 am, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242787 > http://cr.openjdk.java.net/~cjplummer/8242787/webrev.00/index.html > > After fixing JDK-8230731 [1], this test still failed, this time with a > WrongTypeException. The issue is basically the same one as was just > fixed in JDK-8235220 [2]. With CDS on you sometimes get a > WrongTypeException instead of an AddressException, so in some places > code that allows an AddressException needs to also allow a > WrongTypeException. Just an observation: the multiple catch blocks that are identical: 261 catch (AddressException e) { 262 // This is okay at the top of these regions 263 } 264 catch (UnknownOopException e) { 265 // This is okay at the top of these regions 266 } 267 catch (WrongTypeException e) { 268 // This is okay at the top of these regions 269 } can now be written more succinctly as: 261 catch (AddressException | UnknownOopException | WrongTypeException e) { 262 // These are okay at the top of these regions 263 } Cheers, David ----- > Note that fixing this issue then exposes JDK-8242789 [3], which I'll be > fixing next, so the problem list entry changed from JDK-8242787 to > JDK-8242789. > > I also did a bit of cleaning up of some debugging code. During my > debugging session I set DEBUG = true to get some extra debugging output, > and suddenly a lot of tests were failing with a RuntimeException. This > is because of the debugging code I've now stripped out. It decided to > convert an acceptable failure type (UnknownOopException) into one that > the outer try/catch would not catch (RuntimeException). > UnknownOopException is not suppose to cause iterateLiveRegions() to abort. > > https://bugs.openjdk.java.net/browse/JDK-8230731 > https://bugs.openjdk.java.net/browse/JDK-8235220 > https://bugs.openjdk.java.net/browse/JDK-8242789 > > thanks, > > Chris From chris.plummer at oracle.com Fri Apr 17 04:46:24 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 16 Apr 2020 21:46:24 -0700 Subject: RFR(XS) 8242787: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with sun.jvm.hotspot.types.WrongTypeException In-Reply-To: References: Message-ID: On 4/16/20 9:17 PM, David Holmes wrote: > Hi Chris, > > On 17/04/2020 3:18 am, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8242787 >> http://cr.openjdk.java.net/~cjplummer/8242787/webrev.00/index.html >> >> After fixing JDK-8230731 [1], this test still failed, this time with >> a WrongTypeException. The issue is basically the same one as was just >> fixed in JDK-8235220 [2]. With CDS on you sometimes get a >> WrongTypeException instead of an AddressException, so in some places >> code that allows an AddressException needs to also allow a >> WrongTypeException. > > Just an observation: the multiple catch blocks that are identical: > > ?261?????? catch (AddressException e) { > ?262???????? // This is okay at the top of these regions > ?263?????? } > ?264?????? catch (UnknownOopException e) { > ?265???????? // This is okay at the top of these regions > ?266?????? } > ?267?????? catch (WrongTypeException e) { > ?268???????? // This is okay at the top of these regions > ?269?????? } > > can now be written more succinctly as: > > ?261?????? catch (AddressException | UnknownOopException | > WrongTypeException e) { > ?262???????? // These are okay at the top of these regions > ?263?????? } > Ok. I thought I had seen something like that before, but couldn't recall for sure, nor could I recall the syntax. I'll make the change. thanks, Chris > Cheers, > David > ----- > >> Note that fixing this issue then exposes JDK-8242789 [3], which I'll >> be fixing next, so the problem list entry changed from JDK-8242787 to >> JDK-8242789. >> >> I also did a bit of cleaning up of some debugging code. During my >> debugging session I set DEBUG = true to get some extra debugging >> output, and suddenly a lot of tests were failing with a >> RuntimeException. This is because of the debugging code I've now >> stripped out. It decided to convert an acceptable failure type >> (UnknownOopException) into one that the outer try/catch would not >> catch (RuntimeException). UnknownOopException is not suppose to cause >> iterateLiveRegions() to abort. >> >> https://bugs.openjdk.java.net/browse/JDK-8230731 >> https://bugs.openjdk.java.net/browse/JDK-8235220 >> https://bugs.openjdk.java.net/browse/JDK-8242789 >> >> thanks, >> >> Chris From jiefu at tencent.com Fri Apr 17 06:58:42 2020 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Fri, 17 Apr 2020 06:58:42 +0000 Subject: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker(Internet mail) In-Reply-To: References: <7EABDE84-236C-44B9-8599-C7131456131F@tencent.com> Message-ID: Hi Severin, Updated: http://cr.openjdk.java.net/~jiefu/8242480/webrev.02/ Please review it. Thanks a lot. Best regards, Jie ?On 2020/4/16, 11:40 PM, "Severin Gehwolf" wrote: Since you've added a new test, please move them to the jdk docker tests in: test/jdk/jdk/internal/platform/docker/ Fixed. test/hotspot/jtreg/containers/docker/TestGetFreeSwapSpaceSize.java + * @build sun.hotspot.WhiteBox GetFreeSwapSpaceSize + * @run driver ClassFileInstaller -jar whitebox.jar sun.hotspot.WhiteBox sun.hotspot.WhiteBox$WhiteBoxPermission I don't see any reason why WhiteBox would be needed for this test. Is that an oversight or am I missing something? It's my oversight. Thanks for correcting me. From jiefu at tencent.com Fri Apr 17 07:00:17 2020 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Fri, 17 Apr 2020 07:00:17 +0000 Subject: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker(Internet mail) In-Reply-To: <610ae571-58dd-c7d5-d089-9c18acc18a75@oracle.com> References: <7EABDE84-236C-44B9-8599-C7131456131F@tencent.com> <610ae571-58dd-c7d5-d089-9c18acc18a75@oracle.com> Message-ID: <68CADD36-3E89-4653-A2BF-9004D796760B@tencent.com> Hi David, Updated: http://cr.openjdk.java.net/~jiefu/8242480/webrev.02/ The file header had been fixed. Please review it. Thanks a lot. Best regards, Jie ?On 2020/4/17, 11:59 AM, "David Holmes" wrote: Hi Jie, On 16/04/2020 11:23 pm, jiefu(??) wrote: > Hi Severin, > > Thanks for your review and very nice suggestions. > > Updated: http://cr.openjdk.java.net/~jiefu/8242480/webrev.01/ > > test/hotspot/jtreg/containers/docker/TestGetFreeSwapSpaceSize.java is added to reproduce the bug. Can you please use the standard OpenJDK file header after your Tencent copyright line: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ I don't think the "classpath exception" is relevant to tests - certainly other tests I checked do not have it. Thanks, David ----- > Thanks a lot. > Best regards, > Jie > > > On 2020/4/16, 4:40 PM, "Severin Gehwolf" wrote: > > Hi Jie, > > On Fri, 2020-04-10 at 01:49 +0000, jiefu(??) wrote: > > Hi all, > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242480 > > Webrev: http://cr.openjdk.java.net/~jiefu/8242480/webrev.00/ > > > > Negative values were returned by getFreeSwapSpaceSize() in our docker testing. > > The reason is that current implementation doesn't consider the situation when memory.limit_in_bytes == memory.memsw.limit_in_bytes, which means do not use the swap space at all. > > > > In src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java, let's see > > ------------------------------------------------ > > 71 public long getFreeSwapSpaceSize() { > > 72 if (containerMetrics != null) { > > 73 long memSwapLimit = containerMetrics.getMemoryAndSwapLimit(); > > 74 long memLimit = containerMetrics.getMemoryLimit(); > > 75 if (memSwapLimit >= 0 && memLimit >= 0) { > > 76 for (int attempt = 0; attempt < MAX_ATTEMPTS_NUMBER; attempt++) { > > 77 long memSwapUsage = containerMetrics.getMemoryAndSwapUsage(); > > 78 long memUsage = containerMetrics.getMemoryUsage(); > > 79 if (memSwapUsage > 0 && memUsage > 0) { > > 80 // We read "memory usage" and "memory and swap usage" not atomically, > > 81 // and it's possible to get the negative value when subtracting these two. > > 82 // If this happens just retry the loop for a few iterations. > > 83 if ((memSwapUsage - memUsage) >= 0) { > > 84 return memSwapLimit - memLimit - (memSwapUsage - memUsage); > > 85 } > > 86 } > > 87 } > > 88 } > > 89 } > > 90 return getFreeSwapSpaceSize0(); > > 91 } > > ------------------------------------------------ > > If memSwapLimit (@line 73) equals memLimit (@line 74), then getFreeSwapSpaceSize() may return a negative value @line 84. > > > > It would be better to fix it. > > Could you please review it and give me some advice? > > Would this be reproducible via a test? There is > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java which > contains testOperatingSystemMXBeanAwareness() tests. > > It would be good to capture this in a test somehow. > > Thanks, > Severin > > > > From sgehwolf at redhat.com Fri Apr 17 08:51:12 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 Apr 2020 10:51:12 +0200 Subject: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker(Internet mail) In-Reply-To: References: <7EABDE84-236C-44B9-8599-C7131456131F@tencent.com> Message-ID: <23133cdba0148d12d304fd4ccdaa294c6f7e5957.camel@redhat.com> On Fri, 2020-04-17 at 06:58 +0000, jiefu(??) wrote: > Updated: http://cr.openjdk.java.net/~jiefu/8242480/webrev.02/ Looks good. Thanks, Severin From serguei.spitsyn at oracle.com Fri Apr 17 08:58:36 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Apr 2020 01:58:36 -0700 Subject: RFR (T) 8242896: typo #ifdef INCLUDE_JVMTI in codeCache.cpp In-Reply-To: <4c5b7921-632a-fa35-402b-4f322d4af450@oracle.com> References: <048f98a3-4c8c-f691-6aa1-44d72b3020f3@oracle.com> <4c5b7921-632a-fa35-402b-4f322d4af450@oracle.com> Message-ID: <85c87a84-b249-1c32-f8ba-44d1a406abfe@oracle.com> Hi Coleen, LGTM++ On 4/16/20 18:47, David Holmes wrote: > Hi Coleen, > > Still LGTM. The other guarded methods are only called from JVMTI code. > The two that are now stubbed out would have been no-ops without JVMTI > as old_compiled_method_table would have been NULL. > > Still seems trivial to me. This is not that trivial for me. :) But thank you for the comment, David. Thanks, Serguei > > Thanks, > David > > On 17/04/2020 1:14 am, coleen.phillimore at oracle.com wrote: >> >> >> On 4/16/20 10:24 AM, Magnus Ihse Bursie wrote: >>> On 2020-04-16 04:37, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 4/15/20 9:37 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 16/04/2020 10:59 am, coleen.phillimore at oracle.com wrote: >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/2020/8242896.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8242896 >>>>> >>>>> Looks good but ... >>>>> >>>>>> Built and ran vmTestbase RedefineTests which use the protected code. >>>>> >>>>> ... you need to ensure that builds that don't INCLUDE_JVMTI still >>>>> work okay as they will now actually be excluding this code for the >>>>> first time. >>>> >>>> Last time I tried to build minimal, it failed for some odd problem >>>> on my system.? I'll wait until someone from the openjdk can build >>>> it then. >>>> thanks, >>> Building minimal should work.? Try something like this: "jib >>> configure -- --with-jvm-variants=minimal". It should work. >> >> I used to get some error about some X11 library.? I don't remember >> what it was.? Now I get this warning: >> >> The following warnings were produced. Repeated here for convenience: >> WARNING: Ignoring value of PERL from the environment. Use command >> line variables instead. >> >> I'm not sure what it means but it seems to be building. >> >>> >>> I just tried with your patch, and it does not work. >>> >>> /localhome/hg/jdk-BAR/open/src/hotspot/share/classfile/metadataOnStackMark.cpp:70: >>> error: undefined reference to >>> 'CodeCache::old_nmethods_do(MetadataClosure*)' >>> /localhome/hg/jdk-BAR/open/src/hotspot/share/code/nmethod.cpp:1495: >>> error: undefined reference to >>> 'CodeCache::unregister_old_nmethod(CompiledMethod*)' >>> >>> I made a quick check but it was not clear to me if the call sites in >>> metadataOnStackMark.cpp and nmethod.cpp should be excluded if >>> missing jvmti, or if the code in codeCache.cpp should really be >>> present even with jvmti. >> >> They should be excluded. Thanks for testing it for me.? Now it builds >> (up to that point).? Hopefully still trivial. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8242896.02/webrev >> >> Thanks! >> Coleen >>> >>> /Magnus >>> >>> >>>> Coleen >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> thanks, >>>>>> Coleen >>>> >>> >> From coleen.phillimore at oracle.com Fri Apr 17 11:44:14 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Apr 2020 07:44:14 -0400 Subject: RFR (T) 8242896: typo #ifdef INCLUDE_JVMTI in codeCache.cpp In-Reply-To: <4c5b7921-632a-fa35-402b-4f322d4af450@oracle.com> References: <048f98a3-4c8c-f691-6aa1-44d72b3020f3@oracle.com> <4c5b7921-632a-fa35-402b-4f322d4af450@oracle.com> Message-ID: <6c705ec2-dbd0-0bbe-fe2b-2309d4139564@oracle.com> On 4/16/20 9:47 PM, David Holmes wrote: > Hi Coleen, > > Still LGTM. The other guarded methods are only called from JVMTI code. > The two that are now stubbed out would have been no-ops without JVMTI > as old_compiled_method_table would have been NULL. Yes, that is true.? I considered #if INCLUDE_JVMTI around them but then I'd have to change another file. > > Still seems trivial to me. Thanks,? Turned out a bit less trivial than the original 3 characters. Coleen > > Thanks, > David > > On 17/04/2020 1:14 am, coleen.phillimore at oracle.com wrote: >> >> >> On 4/16/20 10:24 AM, Magnus Ihse Bursie wrote: >>> On 2020-04-16 04:37, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 4/15/20 9:37 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 16/04/2020 10:59 am, coleen.phillimore at oracle.com wrote: >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/2020/8242896.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8242896 >>>>> >>>>> Looks good but ... >>>>> >>>>>> Built and ran vmTestbase RedefineTests which use the protected code. >>>>> >>>>> ... you need to ensure that builds that don't INCLUDE_JVMTI still >>>>> work okay as they will now actually be excluding this code for the >>>>> first time. >>>> >>>> Last time I tried to build minimal, it failed for some odd problem >>>> on my system.? I'll wait until someone from the openjdk can build >>>> it then. >>>> thanks, >>> Building minimal should work.? Try something like this: "jib >>> configure -- --with-jvm-variants=minimal". It should work. >> >> I used to get some error about some X11 library.? I don't remember >> what it was.? Now I get this warning: >> >> The following warnings were produced. Repeated here for convenience: >> WARNING: Ignoring value of PERL from the environment. Use command >> line variables instead. >> >> I'm not sure what it means but it seems to be building. >> >>> >>> I just tried with your patch, and it does not work. >>> >>> /localhome/hg/jdk-BAR/open/src/hotspot/share/classfile/metadataOnStackMark.cpp:70: >>> error: undefined reference to >>> 'CodeCache::old_nmethods_do(MetadataClosure*)' >>> /localhome/hg/jdk-BAR/open/src/hotspot/share/code/nmethod.cpp:1495: >>> error: undefined reference to >>> 'CodeCache::unregister_old_nmethod(CompiledMethod*)' >>> >>> I made a quick check but it was not clear to me if the call sites in >>> metadataOnStackMark.cpp and nmethod.cpp should be excluded if >>> missing jvmti, or if the code in codeCache.cpp should really be >>> present even with jvmti. >> >> They should be excluded. Thanks for testing it for me.? Now it builds >> (up to that point).? Hopefully still trivial. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8242896.02/webrev >> >> Thanks! >> Coleen >>> >>> /Magnus >>> >>> >>>> Coleen >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> thanks, >>>>>> Coleen >>>> >>> >> From coleen.phillimore at oracle.com Fri Apr 17 11:44:38 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Apr 2020 07:44:38 -0400 Subject: RFR (T) 8242896: typo #ifdef INCLUDE_JVMTI in codeCache.cpp In-Reply-To: <85c87a84-b249-1c32-f8ba-44d1a406abfe@oracle.com> References: <048f98a3-4c8c-f691-6aa1-44d72b3020f3@oracle.com> <4c5b7921-632a-fa35-402b-4f322d4af450@oracle.com> <85c87a84-b249-1c32-f8ba-44d1a406abfe@oracle.com> Message-ID: <6c3f5a0a-d611-625a-03d4-fb58c9adade3@oracle.com> On 4/17/20 4:58 AM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > LGTM++ > > > On 4/16/20 18:47, David Holmes wrote: >> Hi Coleen, >> >> Still LGTM. The other guarded methods are only called from JVMTI >> code. The two that are now stubbed out would have been no-ops without >> JVMTI as old_compiled_method_table would have been NULL. >> >> Still seems trivial to me. > > This is not that trivial for me. :) > But thank you for the comment, David. Thanks Serguei! Coleen > > Thanks, > Serguei > >> >> Thanks, >> David >> >> On 17/04/2020 1:14 am, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 4/16/20 10:24 AM, Magnus Ihse Bursie wrote: >>>> On 2020-04-16 04:37, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 4/15/20 9:37 PM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 16/04/2020 10:59 am, coleen.phillimore at oracle.com wrote: >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/2020/8242896.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8242896 >>>>>> >>>>>> Looks good but ... >>>>>> >>>>>>> Built and ran vmTestbase RedefineTests which use the protected >>>>>>> code. >>>>>> >>>>>> ... you need to ensure that builds that don't INCLUDE_JVMTI still >>>>>> work okay as they will now actually be excluding this code for >>>>>> the first time. >>>>> >>>>> Last time I tried to build minimal, it failed for some odd problem >>>>> on my system.? I'll wait until someone from the openjdk can build >>>>> it then. >>>>> thanks, >>>> Building minimal should work.? Try something like this: "jib >>>> configure -- --with-jvm-variants=minimal". It should work. >>> >>> I used to get some error about some X11 library.? I don't remember >>> what it was.? Now I get this warning: >>> >>> The following warnings were produced. Repeated here for convenience: >>> WARNING: Ignoring value of PERL from the environment. Use command >>> line variables instead. >>> >>> I'm not sure what it means but it seems to be building. >>> >>>> >>>> I just tried with your patch, and it does not work. >>>> >>>> /localhome/hg/jdk-BAR/open/src/hotspot/share/classfile/metadataOnStackMark.cpp:70: >>>> error: undefined reference to >>>> 'CodeCache::old_nmethods_do(MetadataClosure*)' >>>> /localhome/hg/jdk-BAR/open/src/hotspot/share/code/nmethod.cpp:1495: >>>> error: undefined reference to >>>> 'CodeCache::unregister_old_nmethod(CompiledMethod*)' >>>> >>>> I made a quick check but it was not clear to me if the call sites >>>> in metadataOnStackMark.cpp and nmethod.cpp should be excluded if >>>> missing jvmti, or if the code in codeCache.cpp should really be >>>> present even with jvmti. >>> >>> They should be excluded. Thanks for testing it for me.? Now it >>> builds (up to that point).? Hopefully still trivial. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8242896.02/webrev >>> >>> Thanks! >>> Coleen >>>> >>>> /Magnus >>>> >>>> >>>>> Coleen >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>> >>>> >>> > From david.holmes at oracle.com Fri Apr 17 12:53:37 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Apr 2020 22:53:37 +1000 Subject: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker(Internet mail) In-Reply-To: <68CADD36-3E89-4653-A2BF-9004D796760B@tencent.com> References: <7EABDE84-236C-44B9-8599-C7131456131F@tencent.com> <610ae571-58dd-c7d5-d089-9c18acc18a75@oracle.com> <68CADD36-3E89-4653-A2BF-9004D796760B@tencent.com> Message-ID: <2237a877-f241-e87b-fb9d-106ec272a6a7@oracle.com> On 17/04/2020 5:00 pm, jiefu(??) wrote: > Hi David, > > Updated: http://cr.openjdk.java.net/~jiefu/8242480/webrev.02/ > > The file header had been fixed. Please review it. File header update looks good. Thanks, David > Thanks a lot. > Best regards, > Jie > > ?On 2020/4/17, 11:59 AM, "David Holmes" wrote: > > Hi Jie, > > On 16/04/2020 11:23 pm, jiefu(??) wrote: > > Hi Severin, > > > > Thanks for your review and very nice suggestions. > > > > Updated: http://cr.openjdk.java.net/~jiefu/8242480/webrev.01/ > > > > test/hotspot/jtreg/containers/docker/TestGetFreeSwapSpaceSize.java is added to reproduce the bug. > > > Can you please use the standard OpenJDK file header after your Tencent > copyright line: > > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 only, as > * published by the Free Software Foundation. > * > * This code is distributed in the hope that it will be useful, but WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > * version 2 for more details (a copy is included in the LICENSE file that > * accompanied this code). > * > * You should have received a copy of the GNU General Public License > version > * 2 along with this work; if not, write to the Free Software Foundation, > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > * > * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > > I don't think the "classpath exception" is relevant to tests - certainly > other tests I checked do not have it. > > Thanks, > David > ----- > > > Thanks a lot. > > Best regards, > > Jie > > > > > > On 2020/4/16, 4:40 PM, "Severin Gehwolf" wrote: > > > > Hi Jie, > > > > On Fri, 2020-04-10 at 01:49 +0000, jiefu(??) wrote: > > > Hi all, > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242480 > > > Webrev: http://cr.openjdk.java.net/~jiefu/8242480/webrev.00/ > > > > > > Negative values were returned by getFreeSwapSpaceSize() in our docker testing. > > > The reason is that current implementation doesn't consider the situation when memory.limit_in_bytes == memory.memsw.limit_in_bytes, which means do not use the swap space at all. > > > > > > In src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java, let's see > > > ------------------------------------------------ > > > 71 public long getFreeSwapSpaceSize() { > > > 72 if (containerMetrics != null) { > > > 73 long memSwapLimit = containerMetrics.getMemoryAndSwapLimit(); > > > 74 long memLimit = containerMetrics.getMemoryLimit(); > > > 75 if (memSwapLimit >= 0 && memLimit >= 0) { > > > 76 for (int attempt = 0; attempt < MAX_ATTEMPTS_NUMBER; attempt++) { > > > 77 long memSwapUsage = containerMetrics.getMemoryAndSwapUsage(); > > > 78 long memUsage = containerMetrics.getMemoryUsage(); > > > 79 if (memSwapUsage > 0 && memUsage > 0) { > > > 80 // We read "memory usage" and "memory and swap usage" not atomically, > > > 81 // and it's possible to get the negative value when subtracting these two. > > > 82 // If this happens just retry the loop for a few iterations. > > > 83 if ((memSwapUsage - memUsage) >= 0) { > > > 84 return memSwapLimit - memLimit - (memSwapUsage - memUsage); > > > 85 } > > > 86 } > > > 87 } > > > 88 } > > > 89 } > > > 90 return getFreeSwapSpaceSize0(); > > > 91 } > > > ------------------------------------------------ > > > If memSwapLimit (@line 73) equals memLimit (@line 74), then getFreeSwapSpaceSize() may return a negative value @line 84. > > > > > > It would be better to fix it. > > > Could you please review it and give me some advice? > > > > Would this be reproducible via a test? There is > > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java which > > contains testOperatingSystemMXBeanAwareness() tests. > > > > It would be good to capture this in a test somehow. > > > > Thanks, > > Severin > > > > > > > > > > > From jiefu at tencent.com Fri Apr 17 13:02:46 2020 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Fri, 17 Apr 2020 13:02:46 +0000 Subject: 8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker(Internet mail) In-Reply-To: <2237a877-f241-e87b-fb9d-106ec272a6a7@oracle.com> References: <7EABDE84-236C-44B9-8599-C7131456131F@tencent.com> <610ae571-58dd-c7d5-d089-9c18acc18a75@oracle.com> <68CADD36-3E89-4653-A2BF-9004D796760B@tencent.com> <2237a877-f241-e87b-fb9d-106ec272a6a7@oracle.com> Message-ID: Thanks Severin and David for your review. Will push it tomorrow. Best regards, Jie ?On 2020/4/17, 8:56 PM, "David Holmes" wrote: On 17/04/2020 5:00 pm, jiefu(??) wrote: > Hi David, > > Updated: http://cr.openjdk.java.net/~jiefu/8242480/webrev.02/ > > The file header had been fixed. Please review it. File header update looks good. Thanks, David > Thanks a lot. > Best regards, > Jie > > On 2020/4/17, 11:59 AM, "David Holmes" wrote: > > Hi Jie, > > On 16/04/2020 11:23 pm, jiefu(??) wrote: > > Hi Severin, > > > > Thanks for your review and very nice suggestions. > > > > Updated: http://cr.openjdk.java.net/~jiefu/8242480/webrev.01/ > > > > test/hotspot/jtreg/containers/docker/TestGetFreeSwapSpaceSize.java is added to reproduce the bug. > > > Can you please use the standard OpenJDK file header after your Tencent > copyright line: > > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 only, as > * published by the Free Software Foundation. > * > * This code is distributed in the hope that it will be useful, but WITHOUT > * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > * version 2 for more details (a copy is included in the LICENSE file that > * accompanied this code). > * > * You should have received a copy of the GNU General Public License > version > * 2 along with this work; if not, write to the Free Software Foundation, > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > * > * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > > I don't think the "classpath exception" is relevant to tests - certainly > other tests I checked do not have it. > > Thanks, > David > ----- > > > Thanks a lot. > > Best regards, > > Jie > > > > > > On 2020/4/16, 4:40 PM, "Severin Gehwolf" wrote: > > > > Hi Jie, > > > > On Fri, 2020-04-10 at 01:49 +0000, jiefu(??) wrote: > > > Hi all, > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242480 > > > Webrev: http://cr.openjdk.java.net/~jiefu/8242480/webrev.00/ > > > > > > Negative values were returned by getFreeSwapSpaceSize() in our docker testing. > > > The reason is that current implementation doesn't consider the situation when memory.limit_in_bytes == memory.memsw.limit_in_bytes, which means do not use the swap space at all. > > > > > > In src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java, let's see > > > ------------------------------------------------ > > > 71 public long getFreeSwapSpaceSize() { > > > 72 if (containerMetrics != null) { > > > 73 long memSwapLimit = containerMetrics.getMemoryAndSwapLimit(); > > > 74 long memLimit = containerMetrics.getMemoryLimit(); > > > 75 if (memSwapLimit >= 0 && memLimit >= 0) { > > > 76 for (int attempt = 0; attempt < MAX_ATTEMPTS_NUMBER; attempt++) { > > > 77 long memSwapUsage = containerMetrics.getMemoryAndSwapUsage(); > > > 78 long memUsage = containerMetrics.getMemoryUsage(); > > > 79 if (memSwapUsage > 0 && memUsage > 0) { > > > 80 // We read "memory usage" and "memory and swap usage" not atomically, > > > 81 // and it's possible to get the negative value when subtracting these two. > > > 82 // If this happens just retry the loop for a few iterations. > > > 83 if ((memSwapUsage - memUsage) >= 0) { > > > 84 return memSwapLimit - memLimit - (memSwapUsage - memUsage); > > > 85 } > > > 86 } > > > 87 } > > > 88 } > > > 89 } > > > 90 return getFreeSwapSpaceSize0(); > > > 91 } > > > ------------------------------------------------ > > > If memSwapLimit (@line 73) equals memLimit (@line 74), then getFreeSwapSpaceSize() may return a negative value @line 84. > > > > > > It would be better to fix it. > > > Could you please review it and give me some advice? > > > > Would this be reproducible via a test? There is > > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java which > > contains testOperatingSystemMXBeanAwareness() tests. > > > > It would be good to capture this in a test somehow. > > > > Thanks, > > Severin > > > > > > > > > > > From chris.plummer at oracle.com Fri Apr 17 17:30:06 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 17 Apr 2020 10:30:06 -0700 Subject: RFR(XS) 8242789: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with 'JShellToolProvider' missing from stdout/stderr Message-ID: <0f377e45-63bc-8352-c9b6-984578a706d2@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8242789 http://cr.openjdk.java.net/~cjplummer/8242789/webrev.00 JShellHeapDumpTest.java has two variants, one that does a short 2 second sleep after launching the jshell process (the main JShellHeapDumpTest.java test does this) and the other that does no sleep (HeapDumpTestWithActiveProcess.java does this by invoking JShellHeapDumpTest.java with the "nosleep" argument). The reason for the 2 second sleep is to get the jshell process into a steady state so JDK-8231634 [1] doesn't turn up when using SA on the jshell process. I added the sleep instead of problem listing JShellHeapDumpTest.java since it is a useful? test even with the sleep in place. HeapDumpTestWithActiveProcess.java was added so we still had a test to reproduce JDK-8231634 [1], and was problem listed immediately. However, another side affect of not sleeping is sometimes SA requests the thread dump of the jshell process before jshell enters its main thread. Thus the test can't find the "JShellToolProvider" symbol in the thread dump. The fix is to simply not require the symbol to be present when in "nosleep" mode. thanks, Chris [1] https://bugs.openjdk.java.net/browse/JDK-8231634 From daniil.x.titov at oracle.com Fri Apr 17 20:03:09 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 17 Apr 2020 13:03:09 -0700 Subject: RFR: 8231585: java/lang/management/ThreadMXBean/MaxDepthForThreadInfoTest.java fails with java.lang.NullPointerException Message-ID: <902A52FD-B44F-47C3-8658-969D0CEA2671@oracle.com> Please review the change that fixes intermittent failure of java/lang/management/ThreadMXBean/MaxDepthForThreadInfoTest.java As David noticed (thank you, David, for this analysis) there is no guarantee that all threads found by getAllThreadIds() are still alive by the time we call getThreadInfo() so we have to allow for null array entries. Testing: Mach5 tests with Graal on passed 300 times. [1] http://cr.openjdk.java.net/~dtitov/8231585/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8231585 Best regards, Daniil From chris.plummer at oracle.com Fri Apr 17 21:14:07 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 17 Apr 2020 14:14:07 -0700 Subject: RFR: 8231585: java/lang/management/ThreadMXBean/MaxDepthForThreadInfoTest.java fails with java.lang.NullPointerException In-Reply-To: <902A52FD-B44F-47C3-8658-969D0CEA2671@oracle.com> References: <902A52FD-B44F-47C3-8658-969D0CEA2671@oracle.com> Message-ID: <5f6c86bc-a61f-4894-2b57-362ed6f76e4e@oracle.com> Looks good. Chris On 4/17/20 1:03 PM, Daniil Titov wrote: > Please review the change that fixes intermittent failure of java/lang/management/ThreadMXBean/MaxDepthForThreadInfoTest.java > > As David noticed (thank you, David, for this analysis) there is no guarantee that all threads found by getAllThreadIds() are still alive by the time we call getThreadInfo() so we have to allow for null array entries. > > Testing: Mach5 tests with Graal on passed 300 times. > > [1] http://cr.openjdk.java.net/~dtitov/8231585/webrev.01/ > [2] https://bugs.openjdk.java.net/browse/JDK-8231585 > > Best regards, > Daniil > > From chris.plummer at oracle.com Fri Apr 17 22:51:41 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 17 Apr 2020 15:51:41 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> Message-ID: <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> On 4/16/20 9:45 AM, Mandy Chung wrote: > On 4/14/20 11:51 AM, Paul Sandoz wrote: >> Looks good to me (not familiar with all the code areas. >> >> Minor suggestion: >> >> MethodHandles.java >> >> 1811????????? * ASCII periods. For the instance of {@link >> java.lang.Class} representing {@code C}: >> 1812????????? *
        >> 1813????????? *
      • {@link Class#getName()} returns the string >> {@code GN + "/" + }, >> 1814????????? *????? even though this is not a valid binary class or >> interface name.
        • >> 1815????????? *
      • {@link Class#descriptorString()} returns the string >> 1816????????? *????? {@code "L" + N + ";" + "/" + }, >> 1817????????? *????? even though this is not a valid type descriptor >> name.
        • >> 1818????????? *
      >> >> Add another bullet: >> >> ? >> even though this is not a valid type descriptor name; and >> >> - therefore {@link Class#describeConstable} returns an empty {@code >> Optional}. >> ? >> >> ? > > OK.?? I add this bullet: > > - Class.describeConstable() returns an empty optional as C cannot be > described in nominal form. > > The webrev and spec was updated [1] for descriptor string to be of the > form "Lfoo/Foo.1234;" to mitigate the compatibility risk.? Th > > Specdiff with serviceability spec change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/ > > Specdiff without svc spec change: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-descriptor-string/overview-summary.html > > > Webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-descriptor-string/ > > > Svc spec change webrev: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/ > > > thanks > Mandy > [1] > https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007155.html Hi Mandy, Thanks for updating the svc specs. Some comments below: In the JDWP spec update, you changed "JNI signature" to "type signature" in one place, but left it as "JNI signature" everywhere else. Should they all be changed? In the JDWP spec for ClassLoaderReference.VisibleClasses: ?"That is, this class loader has been recorded as an initiating loader of the returned classes." -> "That is, all classes for which this class loader has been recorded as an initiating loader." This seems like too much detail to be put here. Basically the term "initiating ClassLoader" has turned into a short essay. Is it possible that all this detail could be put elsewhere and referenced? Aren't there other places in other specs where a similar clarification of "initiating ClassLoader" is needed (I see now that ClassLoaderClasses in the JVMTI spec, ClassLoaderReference,visibleClasses in the JDI spec, and Instrumentation.getInitiatedClasses are all dealing with this, but not all in the exact same way). In the JVMTI spec for GetLoadedClasses: This suffers in a way similar to ClassLoaderReference.VisibleClasses in the JDWP spec, although not as badly. A simple concept ends up with a complex description, and it seems that description should really be in a more centralized place. I would also suggest a bit of cleanup of these lines: 6866???????? An array class is created directly by Java virtual machine.? An array class 6867???????? creation can be triggered by using class loaders or by invoking methods in certain 6868???????? Java SE Platform API such as reflection. "Created by [the] Java virtual machine" (add "the") Change "An array class creation" to "The creation" since your are repeating "An array class" from the previous sentence. In the JVMTI spec ClassLoaderClasses section: "That is, initiating_loader has been recorded as an initiating loader of the returned classes." -> "That is, all classes for which initiating_loader has been recorded as an initiating loader." In the JVMTI spec GetClassSignature section: "If the class indicated by klass is ..." -> "If the class ..." (you just finished the previous sentence with "class indicated by Klass"). "the returned name is [the] JNI type signature" (add "the"). Also, is "JNI type signature" formally defined somewhere? This relates to my JDWP spec comment above. " where N is the binary name encoded in internal form indicated by the class file". Is "binary name encoded in internal form" explained somewhere? Also, can you add an example of a returned hidden class signature? In the JVMTI spec ClassLoad section: "representation using [a] class loader" (add "a") "By invoking Lookup::defineHiddenClass, that creates ..."? -> "By invoking Lookup::defineHiddenClass to create ..." "certain Java SE Platform API" -> Should be "APIs" In JDI ClassLoaderReference.definedClasses() "loaded at least to the point of preparation and types ..." -> "loaded at least to the point of preparation, and types ..." (Note, this not a new issue with your edits) In Instrumentation.getAllLoadedClasses: The reference to `class` did not format properly. "by invoking Lookup::defineHiddenClass that creates" -> "by invoking Lookup::defineHiddenClass, which creates" "An array class is created directly by Java virtual machine. An array class creation can be triggered ..." ->"An array class is created directly by the Java virtual machine. Array class creation can be triggered ..." In Instrumentation.getInitiatedClasses: "That is, loader has been recorded as an initiating loader of these classes." -> "That is, all classes for which loader has been recorded as an initiating loader." thanks, Chris > > >> >> Paul. >> >>> On Apr 11, 2020, at 8:13 PM, Mandy Chung >>> wrote: >>> >>> Please review the delta patch: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/ >>> >>> >>> Incremental specdiff: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html >>> >>> This is to follow a discussion [1] on Class::descriptorString and >>> MethodType::descriptorString for hidden classes.?? The proposal is >>> to define the descriptor string for a hidden class of this form: >>> ???? "L" + N + ";" + "/" + >>> >>> The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` >>> and `MethodType::descriptorString` are updated to return the >>> descriptor of this form for a hidden class.?? To support hidden >>> class, `java.lang.invoke.TypeDescriptor` spec is revised such that a >>> `TypeDescriptor` object can represent an entity that may not be >>> described in nominal form.???? This change affects JVM TI, JDWP and >>> JDI.??? The spec change includes a couple other JVM TI and >>> java.instrument spec clarification w.r.t. hidden classes that >>> Serguei has been working on. >>> >>> >>> >>> Mandy >>> [1] >>> https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007093.html >>> >>> ---------------- >>> As a record, the above patch is applied on the top: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06/ >>> >>> >>> webrev.06 includes the following changes that have been reviewed: >>> 1. rename "weak hidden" and Klass::is_hidden_weak to >>> is_non_strong_hidden >>> 2. remove unused `setImplMethod` method from lambda proxy class >>> 3. include Serguei's patch to fix JDK-8242166: regression in JDI >>> ClassUnload events >>> 4. drop the uniqueness guarantee of the suffix of the hidden class's >>> name >>> >>> On 3/31/20 8:01 PM, Mandy Chung wrote: >>>> Thanks to the review feedbacks. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04/ >>>> >>>> Delta between webrev.03 and webrev.04: >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta/ >>>> >>>> >>>> Summary of changes is: >>>> 1. Update javac to retain the previous behavior when compiling to >>>> target release <= 14 where lambda proxy class is not a nestmate >>>> 2. Rename Class::isHiddenClass to Class::isHidden >>>> 3. Address Joe's feedback on the CSR to document the behavior of >>>> the relevant methods in java.lang.Class for hidden classes >>>> 4. Add test case for unloadable class with nest host error >>>> 5. Add test cases for hidden classes with different kinds of class >>>> or interface >>>> 6. Update dcmd to drop "weak hidden class" and refer it as "hidden >>>> class" >>>> 7. Small changes in response to Remi, Coleen, Paul's review comments >>>> 8. Fix copyright headers >>>> 9. Fix @modules in tests >>>> >>>> Most of the changes above have also been reviewed as separate patches. >>>> >>>> Thanks >>>> Mandy >>>> >>>> On 3/26/20 4:57 PM, Mandy Chung wrote: >>>>> Please review the implementation of JEP 371: Hidden Classes. The >>>>> main changes are in core-libs and hotspot runtime area.? Small >>>>> changes are made in javac, VM compiler (intrinsification of >>>>> Class::isHiddenClass), JFR, JDI, and jcmd.? CSR [1]has been >>>>> reviewed and is in the finalized state (see specdiff and javadoc >>>>> below for reference). >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03 >>>>> >>>>> >>>>> javadoc/specdiff >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/ >>>>> >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/ >>>>> >>>>> >>>>> JVMS 5.4.4 change: >>>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf >>>>> >>>>> >>>>> CSR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8238359 >>>>> >>>>> Thanks >>>>> Mandy >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8238359 >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8240338 >>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8230502 > From mandy.chung at oracle.com Fri Apr 17 23:52:09 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 17 Apr 2020 16:52:09 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> Message-ID: <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> On 4/17/20 3:51 PM, Chris Plummer wrote: > Hi Mandy, > > Thanks for updating the svc specs. Some comments below: > > > In the JDWP spec update, you changed "JNI signature" to "type > signature" in one place, but left it as "JNI signature" everywhere > else. Should they all be changed? > JDWP signature is changed because there is no JNI signature representing a hidden class.??? I leave other references to JNI signature as is since those only apply for normal classes as I wanted to keep this change specifically due to hidden classes.? I think it's good to file a JBS issue to follow up on JDWP and JDI to determine if the spec should be upgraded to reference the new TypeDescriptor API. > > In the JDWP spec for ClassLoaderReference.VisibleClasses: > > ?"That is, this class loader has been recorded as an initiating > loader of the returned classes." -> "That is, all classes for which > this class loader has been recorded as an initiating loader." > > This seems like too much detail to be put here. Basically the term > "initiating ClassLoader" has turned into a short essay. Is it possible > that all this detail could be put elsewhere and referenced? Any suggestion??? We attempted to place those description in JVM TI Class section or ClassLoad event.?? However, that's not ideal place since that's needed by JDWP, JDI and Instrumentation.?? I found inlining this description is not ideal but it provides adequate clarification. > Aren't there other places in other specs where a similar clarification > of "initiating ClassLoader" is needed (I see now that > ClassLoaderClasses in the JVMTI spec, > ClassLoaderReference,visibleClasses in the JDI spec, and > Instrumentation.getInitiatedClasses are all dealing with this, but not > all in the exact same way). > I took the conservative side and make sure the clarification is in place for all APIs.? I'm open to any suggestion for example having JDWP and JDI to link to JVM TI spec if you think appropriate. > > In the JVMTI spec for GetLoadedClasses: > > This suffers in a way similar to ClassLoaderReference.VisibleClasses > in the JDWP spec, although not as badly. A simple concept ends up with > a complex description, and it seems that description should really be > in a more centralized place.? I would also suggest a bit of cleanup of > these lines: > > 6866???????? An array class is created directly by Java virtual > machine.? An array class > 6867???????? creation can be triggered by using class loaders or by > invoking methods in certain > 6868???????? Java SE Platform API such as reflection. > > "Created by [the] Java virtual machine" (add "the") > Change "An array class creation" to "The creation" since your are > repeating "An array class" from the previous sentence. > > > In the JVMTI spec ClassLoaderClasses section: > > "That is, initiating_loader has been recorded as an initiating loader > of the returned classes." -> "That is, all classes for which > initiating_loader has been recorded as an initiating loader." > > > In the JVMTI spec GetClassSignature section: > > "If the class indicated by klass is ..." -> "If the class ..." (you > just finished the previous sentence with "class indicated by Klass"). > > "the returned name is [the] JNI type signature" (add "the"). Also, is > "JNI type signature" formally defined somewhere? This relates to my > JDWP spec comment above. > It's a link to https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures. This is how the current JVM TI spec defines. > " where N is the binary name encoded in internal form indicated by the > class file". Is "binary name encoded in internal form" explained > somewhere? JVMS 4.2.1 https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.2.1 > Also, can you add an example of a returned hidden class signature? > OK > > In the JVMTI spec ClassLoad section: > > "representation using [a] class loader" (add "a") > > "By invoking Lookup::defineHiddenClass, that creates ..."? -> "By > invoking Lookup::defineHiddenClass to create ..." > > "certain Java SE Platform API" -> Should be "APIs" > > > In JDI ClassLoaderReference.definedClasses() > > "loaded at least to the point of preparation and types ..." -> "loaded > at least to the point of preparation, and types ..." (Note, this not a > new issue with your edits) > > > In Instrumentation.getAllLoadedClasses: > > The reference to `class` did not format properly. > Serguei caught that one too.? I fixed it in my local repo. > "by invoking Lookup::defineHiddenClass that creates" -> "by invoking > Lookup::defineHiddenClass, which creates" > > "An array class is created directly by Java virtual machine. An array > class creation can be triggered ..." ->"An array class is created > directly by the Java virtual machine. Array class creation can be > triggered ..." > > > In Instrumentation.getInitiatedClasses: > > "That is, loader has been recorded as an initiating loader of these > classes." -> "That is, all classes for which loader has been recorded > as an initiating loader." > > thanks, > > Chris Thanks for the review.?? See this patch of the editorial fixes. diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec --- a/make/data/jdwp/jdwp.spec +++ b/make/data/jdwp/jdwp.spec @@ -2265,8 +2265,8 @@ ???????? "Returns a list of all classes which this class loader can find " ???????? "by name via ClassLoader::loadClass, " ???????? "Class::forName and bytecode linkage. That is, " -??????? "this class loader has been recorded as an initiating " -??????? "loader of the returned classes. The list contains each +??????? "all classes for which this class loader has been recorded as an " +??????? "initiating loader. The list contains each " ???????? "reference type created by this loader and any types for which " ???????? "loading was delegated by this class loader to another class loader. " ???????? "The list does not include hidden classes or interfaces created by " diff --git a/src/hotspot/share/prims/jvmti.xml b/src/hotspot/share/prims/jvmti.xml --- a/src/hotspot/share/prims/jvmti.xml +++ b/src/hotspot/share/prims/jvmti.xml @@ -6857,15 +6857,15 @@ ???????? A class or interface creation can be triggered by one of the following: ????????
        ????????
      • By loading and deriving a class from a class file representation -??????????? using class loader (see ).
        • +??????????? using a class loader (see ). ????????
      • By invoking Lookup::defineHiddenClass ???????????? that creates a hidden class or interface from a class file representation.
        • -???????
      • By invoking methods in certain Java SE Platform API such as reflection.
        • +???????
      • By invoking methods in certain Java SE Platform APIs such as reflection.
        • ?????????
      ????????

      -??????? An array class is created directly by Java virtual machine.? An array class -??????? creation can be triggered by using class loaders or by invoking methods in certain -??????? Java SE Platform API such as reflection. +??????? An array class is created directly by the Java virtual machine.? The creation +??????? can be triggered by using class loaders or by invoking methods in certain +??????? Java SE Platform APIs such as reflection. ????????

      ???????? The returned list includes all classes and interfaces, including ???????? @@ -6904,8 +6904,8 @@ ???????? can find by name via ???????? ClassLoader::loadClass, ???????? Class::forName and bytecode linkage. -??????? That is, initiating_loader -??????? has been recorded as an initiating loader of the returned classes. +??????? That is, all classes for which initiating_loader +??????? has been recorded as an initiating loader. ???????? Each class in the returned array was created by this class loader, ???????? either by defining it directly or by delegation to another class loader. ???????? See . @@ -6964,21 +6964,22 @@ ?????? ???????? Return the name and the generic signature of the class indicated by klass. ????????

      -??????? If the class indicated by klass is a class or interface, then: +??????? If the class is a class or interface, then: ????????

        ????????
      • If the class or interface is not hi dden, -????????? then the returned name is +????????? then the returned name is the ?????????? JNI type signature. ?????????? For example, java.util.List is "Ljava/util/List;" ????????
        • ????????
      • If the class or interface is hidden , ?????????? then the returned name is a string of the form: ?????????? "L" + N + "." +? S + ";" -????????? where N is the binary name encoded in internal form +????????? where N is the binary name encoded in internal form (JVMS 4.2.1) ?????????? indicated by the class file passed to ?????????? Lookup::defineHiddenClass, ?????????? and S is an unqualified name. -????????? The returned name is not a valid type descriptor. +????????? The returned name is not a type descriptor and does not conform to JVMS 4.3.2. +????????? For example, com.foo.Foo/AnySuffix is "Lcom/foo/Foo.AnySuffix;" ????????
        • ????????
      ????????

      @@ -12768,10 +12769,10 @@ ?????? A class or interface is created by one of the following: ??????

        ??????
      • By loading and deriving a class from a class file representation -????????? using class loader.
        • +????????? using a class loader. ??????
      • By invoking Lookup::defineHiddenClass, ?????????? that creates a hidden class or interface from a class file representation.
        • -?????
      • By invoking methods in certain Java SE Platform API such as reflection.
        • +?????
      • By invoking methods in certain Java SE Platform APIs such as reflection.
        • ??????
      ??????

      ?????? Array class creation does not generate a class load event. diff --git a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java --- a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java +++ b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java @@ -392,15 +392,15 @@ ????? * A class or interface creation can be triggered by one of the following: ????? *

        ????? *
      • by loading and deriving a class from a {@code class} file representation -???? *???? using class loader (see JVMS {@jvms 5.3}). +???? *???? using a class loader (see JVMS {@jvms 5.3}). ????? *
      • by invoking {@link java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) -???? *???? Lookup::defineHiddenClass} that creates a {@link Class#isHidden +???? *???? Lookup::defineHiddenClass}, which creates a {@link Class#isHidden ????? *???? hidden class or interface} from a {@code class} file representation. ????? *
      • by invoking methods in certain reflection APIs such as ????? *???? {@link Class#forName(String) Class::forName}. ????? *
      ????? *

      -???? * An array class is created directly by Java virtual machine. An array +???? * An array class is created directly by the Java virtual machine.? Array ????? * class creation can be triggered by using class loaders or by invoking ????? * methods in certain reflection APIs such as ????? * {@link java.lang.reflect.Array#newInstance(Class, int) Array::newInstance} @@ -420,8 +420,8 @@ ????? * Returns an array of all classes which {@code loader} can find by name ????? * via {@link ClassLoader#loadClass(String, boolean) ClassLoader::loadClass}, ????? * {@link Class#forName(String) Class::forName} and bytecode linkage. -???? * That is, {@code loader} has been recorded as an initiating loader -???? * of these classes. If the supplied {@code loader} is {@code null}, +???? * That is, all classes for which {@code loader} has been recorded as +???? * an initiating loader. If the supplied {@code loader} is {@code null}, ????? * classes that the bootstrap class loader can find by name are returned. ????? * ????? *

      diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java @@ -46,7 +46,7 @@ ????? * No ordering of this list guaranteed. ????? * The returned list will include all reference types, including ????? * {@link Class#isHidden hidden classes or interfaces}, loaded -???? * at least to the point of preparation and types (like array) +???? * at least to the point of preparation, and types (like array) ????? * for which preparation is not defined. ????? * ????? * @return a {@code List} of {@link ReferenceType} objects mirroring types @@ -59,8 +59,8 @@ ????? * Returns a list of all classes which this class loader ????? * can find by name via {@link ClassLoader#loadClass(String, boolean) ????? * ClassLoader::loadClass}, {@link Class#forName(String) Class::forName} -???? * and bytecode linkage in the target VM.? That is, this class loader -???? * has been recorded as an initiating loader of these classes. +???? * and bytecode linkage in the target VM.? That is, all classes for +???? * which this class loader has been recorded as an initiating loader. ????? *

      ????? * Each class in the returned list was created by this class loader ????? * either by defining it directly or by delegation to another class loader diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java @@ -138,9 +138,9 @@ ????? * A class or interface creation can be triggered by one of the following: ????? *

        ????? *
      • by loading and deriving a class from a {@code class} file representation -???? *???? using class loader (see JVMS {@jvms 5.3}). +???? *???? using a class loader (see JVMS {@jvms 5.3}). ????? *
      • by invoking {@link java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) -???? *???? Lookup::defineHiddenClass} that creates a {@link Class#isHidden +???? *???? Lookup::defineHiddenClass}, which creates a {@link Class#isHidden ????? *???? hidden class or interface} from a {@code class} file representation. ????? *
      • by invoking methods in certain reflection APIs such as ????? *???? {@link Class#forName(String) Class::forName}. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Apr 18 04:37:21 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Apr 2020 21:37:21 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> Message-ID: On 4/17/20 16:52, Mandy Chung wrote: > > > On 4/17/20 3:51 PM, Chris Plummer wrote: >> Hi Mandy, >> >> Thanks for updating the svc specs. Some comments below: >> >> >> In the JDWP spec update, you changed "JNI signature" to "type >> signature" in one place, but left it as "JNI signature" everywhere >> else. Should they all be changed? >> > > JDWP signature is changed because there is no JNI signature > representing a hidden class.??? I leave other references to JNI > signature as is since those only apply for normal classes as I wanted > to keep this change specifically due to hidden classes.? I think it's > good to file a JBS issue to follow up on JDWP and JDI to determine if > the spec should be upgraded to reference the new TypeDescriptor API. > >> >> In the JDWP spec for ClassLoaderReference.VisibleClasses: >> >> ?"That is, this class loader has been recorded as an >> initiating loader of the returned classes." -> "That is, all >> classes for which this class loader has been recorded as an >> initiating loader." >> >> This seems like too much detail to be put here. Basically the term >> "initiating ClassLoader" has turned into a short essay. Is it >> possible that all this detail could be put elsewhere and referenced? > > Any suggestion??? We attempted to place those description in JVM TI > Class section or ClassLoad event.?? However, that's not ideal place > since that's needed by JDWP, JDI and Instrumentation.?? I found > inlining this description is not ideal but it provides adequate > clarification. The JDI (transitively via JDWP), JDWP and Instrumentation implementations are based on the JVMTI. I've tried to suggest once to link these API's to the JVMTI. The problem is there was no such practice in the specs of these API's before but we can make a step to introduce it now. Placing this description either in JVM TI Class section or ClassLoad event would be good enough. An alternative approach is to make JVMTI/JDI/JDWP/Instrument to refer to the java.lang.Class spec for general information about class loading and classes defined and initiated by class loaders. Thanks, Serguei >> Aren't there other places in other specs where a similar >> clarification of "initiating ClassLoader" is needed (I see now that >> ClassLoaderClasses in the JVMTI spec, >> ClassLoaderReference,visibleClasses in the JDI spec, and >> Instrumentation.getInitiatedClasses are all dealing with this, but >> not all in the exact same way). >> > > I took the conservative side and make sure the clarification is in > place for all APIs.? I'm open to any suggestion for example having > JDWP and JDI to link to JVM TI spec if you think appropriate. > >> >> In the JVMTI spec for GetLoadedClasses: >> >> This suffers in a way similar to ClassLoaderReference.VisibleClasses >> in the JDWP spec, although not as badly. A simple concept ends up >> with a complex description, and it seems that description should >> really be in a more centralized place.? I would also suggest a bit of >> cleanup of these lines: >> >> 6866???????? An array class is created directly by Java virtual >> machine.? An array class >> 6867???????? creation can be triggered by using class loaders or by >> invoking methods in certain >> 6868???????? Java SE Platform API such as reflection. >> >> "Created by [the] Java virtual machine" (add "the") >> Change "An array class creation" to "The creation" since your are >> repeating "An array class" from the previous sentence. >> >> >> In the JVMTI spec ClassLoaderClasses section: >> >> "That is, initiating_loader has been recorded as an initiating loader >> of the returned classes." -> "That is, all classes for which >> initiating_loader has been recorded as an initiating loader." >> >> >> In the JVMTI spec GetClassSignature section: >> >> "If the class indicated by klass is ..." -> "If the class ..." (you >> just finished the previous sentence with "class indicated by Klass"). >> >> "the returned name is [the] JNI type signature" (add "the"). Also, is >> "JNI type signature" formally defined somewhere? This relates to my >> JDWP spec comment above. >> > > It's a link to > https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures. > This is how the current JVM TI spec defines. > >> " where N is the binary name encoded in internal form indicated by >> the class file". Is "binary name encoded in internal form" explained >> somewhere? > > JVMS 4.2.1 > > https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.2.1 > > >> Also, can you add an example of a returned hidden class signature? >> > OK > >> >> In the JVMTI spec ClassLoad section: >> >> "representation using [a] class loader" (add "a") >> >> "By invoking Lookup::defineHiddenClass, that creates ..."? -> "By >> invoking Lookup::defineHiddenClass to create ..." >> >> "certain Java SE Platform API" -> Should be "APIs" >> >> >> In JDI ClassLoaderReference.definedClasses() >> >> "loaded at least to the point of preparation and types ..." -> >> "loaded at least to the point of preparation, and types ..." (Note, >> this not a new issue with your edits) >> >> >> In Instrumentation.getAllLoadedClasses: >> >> The reference to `class` did not format properly. >> > > Serguei caught that one too.? I fixed it in my local repo. > >> "by invoking Lookup::defineHiddenClass that creates" -> "by invoking >> Lookup::defineHiddenClass, which creates" >> >> "An array class is created directly by Java virtual machine. An array >> class creation can be triggered ..." ->"An array class is created >> directly by the Java virtual machine. Array class creation can be >> triggered ..." >> >> >> In Instrumentation.getInitiatedClasses: >> >> "That is, loader has been recorded as an initiating loader of these >> classes." -> "That is, all classes for which loader has been recorded >> as an initiating loader." >> >> thanks, >> >> Chris > > Thanks for the review.?? See this patch of the editorial fixes. > > diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec > --- a/make/data/jdwp/jdwp.spec > +++ b/make/data/jdwp/jdwp.spec > @@ -2265,8 +2265,8 @@ > ???????? "Returns a list of all classes which this class loader can > find " > ???????? "by name via ClassLoader::loadClass, " > ???????? "Class::forName and bytecode linkage. That is, " > -??????? "this class loader has been recorded as an initiating " > -??????? "loader of the returned classes. The list contains each > +??????? "all classes for which this class loader has been recorded as > an " > +??????? "initiating loader. The list contains each " > ???????? "reference type created by this loader and any types for which " > ???????? "loading was delegated by this class loader to another class > loader. " > ???????? "The list does not include hidden classes or interfaces > created by " > diff --git a/src/hotspot/share/prims/jvmti.xml > b/src/hotspot/share/prims/jvmti.xml > --- a/src/hotspot/share/prims/jvmti.xml > +++ b/src/hotspot/share/prims/jvmti.xml > @@ -6857,15 +6857,15 @@ > ???????? A class or interface creation can be triggered by one of the > following: > ????????
          > ????????
        • By loading and deriving a class from a class > file representation > -??????????? using class loader (see ).
          • > +??????????? using a class loader (see ). > ????????
        • By invoking id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass > ???????????? that creates a hidden class or interface from a > class file representation.
          • > -???????
        • By invoking methods in certain Java SE Platform API such > as reflection.
          • > +???????
        • By invoking methods in certain Java SE Platform APIs such > as reflection.
          • > ?????????
        > ????????

        > -??????? An array class is created directly by Java virtual machine.? > An array class > -??????? creation can be triggered by using class loaders or by > invoking methods in certain > -??????? Java SE Platform API such as reflection. > +??????? An array class is created directly by the Java virtual > machine.? The creation > +??????? can be triggered by using class loaders or by invoking > methods in certain > +??????? Java SE Platform APIs such as reflection. > ????????

        > ???????? The returned list includes all classes and interfaces, including > ???????? id="../api/java.base/java/lang/Class.html#isHidden()"> > @@ -6904,8 +6904,8 @@ > ???????? can find by name via > ???????? id="../api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean)">ClassLoader::loadClass, > ???????? id="../api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)">Class::forName > and bytecode linkage. > -??????? That is, initiating_loader > -??????? has been recorded as an initiating loader of the returned > classes. > +??????? That is, all classes for which initiating_loader > +??????? has been recorded as an initiating loader. > ???????? Each class in the returned array was created by this class > loader, > ???????? either by defining it directly or by delegation to another > class loader. > ???????? See . > @@ -6964,21 +6964,22 @@ > ?????? > ???????? Return the name and the generic signature of the class > indicated by klass. > ????????

        > -??????? If the class indicated by klass is a class or > interface, then: > +??????? If the class is a class or interface, then: > ????????

          > ????????
        • If the class or interface is not id="../api/java.base/java/lang/Class.html#isHidden()">hi > dden, > -????????? then the returned name is id="jni/types.html#type-signatures"> > +????????? then the returned name is the id="jni/types.html#type-signatures"> > ?????????? JNI type signature. > ?????????? For example, java.util.List is "Ljava/util/List;" > ????????
          • > ????????
        • If the class or interface is id="../api/java.base/java/lang/Class.html#isHidden()">hidden > , > ?????????? then the returned name is a string of the form: > ?????????? "L" + N + "." +? S + ";" > -????????? where N is the binary name encoded in internal > form > +????????? where N is the binary name encoded in internal > form (JVMS 4.2.1) > ?????????? indicated by the class file passed to > ?????????? id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass, > ?????????? and S is an unqualified name. > -????????? The returned name is not a valid type descriptor. > +????????? The returned name is not a type descriptor and does not > conform to JVMS 4.3.2. > +????????? For example, com.foo.Foo/AnySuffix is > "Lcom/foo/Foo.AnySuffix;" > ????????
          • > ????????
        > ????????

        > @@ -12768,10 +12769,10 @@ > ?????? A class or interface is created by one of the following: > ??????

          > ??????
        • By loading and deriving a class from a class > file representation > -????????? using class loader.
          • > +????????? using a class loader. > ??????
        • By invoking id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass, > ?????????? that creates a hidden class or interface from a > class file representation.
          • > -?????
        • By invoking methods in certain Java SE Platform API such as > reflection.
          • > +?????
        • By invoking methods in certain Java SE Platform APIs such > as reflection.
          • > ??????
        > ??????

        > ?????? Array class creation does not generate a class load event. > diff --git > a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > > --- > a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > +++ > b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > @@ -392,15 +392,15 @@ > ????? * A class or interface creation can be triggered by one of the > following: > ????? *

          > ????? *
        • by loading and deriving a class from a {@code class} file > representation > -???? *???? using class loader (see JVMS {@jvms 5.3}). > +???? *???? using a class loader (see JVMS {@jvms 5.3}). > ????? *
        • by invoking {@link > java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], > boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) > -???? *???? Lookup::defineHiddenClass} that creates a {@link > Class#isHidden > +???? *???? Lookup::defineHiddenClass}, which creates a {@link > Class#isHidden > ????? *???? hidden class or interface} from a {@code class} file > representation. > ????? *
        • by invoking methods in certain reflection APIs such as > ????? *???? {@link Class#forName(String) Class::forName}. > ????? *
        > ????? *

        > -???? * An array class is created directly by Java virtual machine. An > array > +???? * An array class is created directly by the Java virtual > machine.? Array > ????? * class creation can be triggered by using class loaders or by > invoking > ????? * methods in certain reflection APIs such as > ????? * {@link java.lang.reflect.Array#newInstance(Class, int) > Array::newInstance} > @@ -420,8 +420,8 @@ > ????? * Returns an array of all classes which {@code loader} can find > by name > ????? * via {@link ClassLoader#loadClass(String, boolean) > ClassLoader::loadClass}, > ????? * {@link Class#forName(String) Class::forName} and bytecode > linkage. > -???? * That is, {@code loader} has been recorded as an initiating loader > -???? * of these classes. If the supplied {@code loader} is {@code null}, > +???? * That is, all classes for which {@code loader} has been > recorded as > +???? * an initiating loader. If the supplied {@code loader} is {@code > null}, > ????? * classes that the bootstrap class loader can find by name are > returned. > ????? * > ????? *

        > diff --git > a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > @@ -46,7 +46,7 @@ > ????? * No ordering of this list guaranteed. > ????? * The returned list will include all reference types, including > ????? * {@link Class#isHidden hidden classes or interfaces}, loaded > -???? * at least to the point of preparation and types (like array) > +???? * at least to the point of preparation, and types (like array) > ????? * for which preparation is not defined. > ????? * > ????? * @return a {@code List} of {@link ReferenceType} objects > mirroring types > @@ -59,8 +59,8 @@ > ????? * Returns a list of all classes which this class loader > ????? * can find by name via {@link ClassLoader#loadClass(String, > boolean) > ????? * ClassLoader::loadClass}, {@link Class#forName(String) > Class::forName} > -???? * and bytecode linkage in the target VM.? That is, this class > loader > -???? * has been recorded as an initiating loader of these classes. > +???? * and bytecode linkage in the target VM.? That is, all classes for > +???? * which this class loader has been recorded as an initiating > loader. > ????? *

        > ????? * Each class in the returned list was created by this class loader > ????? * either by defining it directly or by delegation to another > class loader > diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > @@ -138,9 +138,9 @@ > ????? * A class or interface creation can be triggered by one of the > following: > ????? *

          > ????? *
        • by loading and deriving a class from a {@code class} file > representation > -???? *???? using class loader (see JVMS {@jvms 5.3}). > +???? *???? using a class loader (see JVMS {@jvms 5.3}). > ????? *
        • by invoking {@link > java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], > boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) > -???? *???? Lookup::defineHiddenClass} that creates a {@link > Class#isHidden > +???? *???? Lookup::defineHiddenClass}, which creates a {@link > Class#isHidden > ????? *???? hidden class or interface} from a {@code class} file > representation. > ????? *
        • by invoking methods in certain reflection APIs such as > ????? *???? {@link Class#forName(String) Class::forName}. > > Mandy > > From serguei.spitsyn at oracle.com Sat Apr 18 05:54:37 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Apr 2020 22:54:37 -0700 Subject: RFR: 8231585: java/lang/management/ThreadMXBean/MaxDepthForThreadInfoTest.java fails with java.lang.NullPointerException In-Reply-To: <5f6c86bc-a61f-4894-2b57-362ed6f76e4e@oracle.com> References: <902A52FD-B44F-47C3-8658-969D0CEA2671@oracle.com> <5f6c86bc-a61f-4894-2b57-362ed6f76e4e@oracle.com> Message-ID: Hi Daniil, LGTM++ Thanks, Serguei On 4/17/20 14:14, Chris Plummer wrote: > Looks good. > > Chris > > On 4/17/20 1:03 PM, Daniil Titov wrote: >> Please review the change that fixes intermittent failure of >> java/lang/management/ThreadMXBean/MaxDepthForThreadInfoTest.java >> >> As David noticed (thank you, David, for this analysis) there is no >> guarantee that all threads found by getAllThreadIds() are still alive >> by the time we call getThreadInfo() so we have to allow for null >> array entries. >> >> Testing:? Mach5 tests with Graal on passed 300 times. >> >> [1] http://cr.openjdk.java.net/~dtitov/8231585/webrev.01/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8231585 >> >> Best regards, >> Daniil >> >> > From chris.plummer at oracle.com Sat Apr 18 07:18:59 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 18 Apr 2020 00:18:59 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> Message-ID: <9b74fc5f-0cb0-e0f5-6a36-969db3deff0a@oracle.com> On 4/17/20 9:37 PM, serguei.spitsyn at oracle.com wrote: > On 4/17/20 16:52, Mandy Chung wrote: >> >> >> On 4/17/20 3:51 PM, Chris Plummer wrote: >>> Hi Mandy, >>> >>> Thanks for updating the svc specs. Some comments below: >>> >>> >>> In the JDWP spec update, you changed "JNI signature" to "type >>> signature" in one place, but left it as "JNI signature" everywhere >>> else. Should they all be changed? >>> >> >> JDWP signature is changed because there is no JNI signature >> representing a hidden class.??? I leave other references to JNI >> signature as is since those only apply for normal classes as I wanted >> to keep this change specifically due to hidden classes. I think it's >> good to file a JBS issue to follow up on JDWP and JDI to determine if >> the spec should be upgraded to reference the new TypeDescriptor API. >> >>> >>> In the JDWP spec for ClassLoaderReference.VisibleClasses: >>> >>> ?"That is, this class loader has been recorded as an >>> initiating loader of the returned classes." -> "That is, all >>> classes for which this class loader has been recorded as an >>> initiating loader." >>> >>> This seems like too much detail to be put here. Basically the term >>> "initiating ClassLoader" has turned into a short essay. Is it >>> possible that all this detail could be put elsewhere and referenced? >> >> Any suggestion??? We attempted to place those description in JVM TI >> Class section or ClassLoad event.?? However, that's not ideal place >> since that's needed by JDWP, JDI and Instrumentation.?? I found >> inlining this description is not ideal but it provides adequate >> clarification. > > The JDI (transitively via JDWP), JDWP and Instrumentation > implementations are based on the JVMTI. > I've tried to suggest once to link these API's to the JVMTI. > The problem is there was no such practice in the specs of these API's > before but we can make a step to introduce it now. > Placing this description either in JVM TI Class section or ClassLoad > event would be good enough. > > An alternative approach is to make JVMTI/JDI/JDWP/Instrument to refer > to the java.lang.Class spec for > general information about class loading and classes defined and > initiated by class loaders. I'd first like to clarify on my comment above just in case there was any confusion. At the last minute I re-ordered the two paragraph and now I see it makes it seem like I was only referring to to the one sentence about initiating loaders. I was referring to pretty much all the changes that were made in this section and other similar APIs in the other specs. Yes. I'd like to see all this as part of the Class/Classloading spec in some sort of section that gives an overview of all these topics, but mostly clarifies what an initiating loader is, and the (non) relationship to hidden classes. thanks, Chris > > Thanks, > Serguei > >>> Aren't there other places in other specs where a similar >>> clarification of "initiating ClassLoader" is needed (I see now that >>> ClassLoaderClasses in the JVMTI spec, >>> ClassLoaderReference,visibleClasses in the JDI spec, and >>> Instrumentation.getInitiatedClasses are all dealing with this, but >>> not all in the exact same way). >>> >> >> I took the conservative side and make sure the clarification is in >> place for all APIs.? I'm open to any suggestion for example having >> JDWP and JDI to link to JVM TI spec if you think appropriate. >> >>> >>> In the JVMTI spec for GetLoadedClasses: >>> >>> This suffers in a way similar to ClassLoaderReference.VisibleClasses >>> in the JDWP spec, although not as badly. A simple concept ends up >>> with a complex description, and it seems that description should >>> really be in a more centralized place.? I would also suggest a bit >>> of cleanup of these lines: >>> >>> 6866???????? An array class is created directly by Java virtual >>> machine.? An array class >>> 6867???????? creation can be triggered by using class loaders or by >>> invoking methods in certain >>> 6868???????? Java SE Platform API such as reflection. >>> >>> "Created by [the] Java virtual machine" (add "the") >>> Change "An array class creation" to "The creation" since your are >>> repeating "An array class" from the previous sentence. >>> >>> >>> In the JVMTI spec ClassLoaderClasses section: >>> >>> "That is, initiating_loader has been recorded as an initiating >>> loader of the returned classes." -> "That is, all classes for which >>> initiating_loader has been recorded as an initiating loader." >>> >>> >>> In the JVMTI spec GetClassSignature section: >>> >>> "If the class indicated by klass is ..." -> "If the class ..." (you >>> just finished the previous sentence with "class indicated by Klass"). >>> >>> "the returned name is [the] JNI type signature" (add "the"). Also, >>> is "JNI type signature" formally defined somewhere? This relates to >>> my JDWP spec comment above. >>> >> >> It's a link to >> https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures. >> This is how the current JVM TI spec defines. >> >>> " where N is the binary name encoded in internal form indicated by >>> the class file". Is "binary name encoded in internal form" explained >>> somewhere? >> >> JVMS 4.2.1 >> >> https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.2.1 >> >> >>> Also, can you add an example of a returned hidden class signature? >>> >> OK >> >>> >>> In the JVMTI spec ClassLoad section: >>> >>> "representation using [a] class loader" (add "a") >>> >>> "By invoking Lookup::defineHiddenClass, that creates ..." -> "By >>> invoking Lookup::defineHiddenClass to create ..." >>> >>> "certain Java SE Platform API" -> Should be "APIs" >>> >>> >>> In JDI ClassLoaderReference.definedClasses() >>> >>> "loaded at least to the point of preparation and types ..." -> >>> "loaded at least to the point of preparation, and types ..." (Note, >>> this not a new issue with your edits) >>> >>> >>> In Instrumentation.getAllLoadedClasses: >>> >>> The reference to `class` did not format properly. >>> >> >> Serguei caught that one too.? I fixed it in my local repo. >> >>> "by invoking Lookup::defineHiddenClass that creates" -> "by invoking >>> Lookup::defineHiddenClass, which creates" >>> >>> "An array class is created directly by Java virtual machine. An >>> array class creation can be triggered ..." ->"An array class is >>> created directly by the Java virtual machine. Array class creation >>> can be triggered ..." >>> >>> >>> In Instrumentation.getInitiatedClasses: >>> >>> "That is, loader has been recorded as an initiating loader of these >>> classes." -> "That is, all classes for which loader has been >>> recorded as an initiating loader." >>> >>> thanks, >>> >>> Chris >> >> Thanks for the review.?? See this patch of the editorial fixes. >> >> diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec >> --- a/make/data/jdwp/jdwp.spec >> +++ b/make/data/jdwp/jdwp.spec >> @@ -2265,8 +2265,8 @@ >> ???????? "Returns a list of all classes which this class loader can >> find " >> ???????? "by name via ClassLoader::loadClass, " >> ???????? "Class::forName and bytecode linkage. That is, " >> -??????? "this class loader has been recorded as an initiating " >> -??????? "loader of the returned classes. The list contains each >> +??????? "all classes for which this class loader has been recorded >> as an " >> +??????? "initiating loader. The list contains each " >> ???????? "reference type created by this loader and any types for >> which " >> ???????? "loading was delegated by this class loader to another class >> loader. " >> ???????? "The list does not include hidden classes or interfaces >> created by " >> diff --git a/src/hotspot/share/prims/jvmti.xml >> b/src/hotspot/share/prims/jvmti.xml >> --- a/src/hotspot/share/prims/jvmti.xml >> +++ b/src/hotspot/share/prims/jvmti.xml >> @@ -6857,15 +6857,15 @@ >> ???????? A class or interface creation can be triggered by one of the >> following: >> ????????
            >> ????????
          • By loading and deriving a class from a >> class file representation >> -??????????? using class loader (see ).
            • >> +??????????? using a class loader (see ). >> ????????
          • By invoking > id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass >> ???????????? that creates a hidden class or interface from a >> class file representation.
            • >> -???????
          • By invoking methods in certain Java SE Platform API such >> as reflection.
            • >> +???????
          • By invoking methods in certain Java SE Platform APIs >> such as reflection.
            • >> ?????????
          >> ????????

          >> -??????? An array class is created directly by Java virtual machine.? >> An array class >> -??????? creation can be triggered by using class loaders or by >> invoking methods in certain >> -??????? Java SE Platform API such as reflection. >> +??????? An array class is created directly by the Java virtual >> machine.? The creation >> +??????? can be triggered by using class loaders or by invoking >> methods in certain >> +??????? Java SE Platform APIs such as reflection. >> ????????

          >> ???????? The returned list includes all classes and interfaces, >> including >> ???????? > id="../api/java.base/java/lang/Class.html#isHidden()"> >> @@ -6904,8 +6904,8 @@ >> ???????? can find by name via >> ???????? > id="../api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean)">ClassLoader::loadClass, >> ???????? > id="../api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)">Class::forName >> and bytecode linkage. >> -??????? That is, initiating_loader >> -??????? has been recorded as an initiating loader of the returned >> classes. >> +??????? That is, all classes for which initiating_loader >> +??????? has been recorded as an initiating loader. >> ???????? Each class in the returned array was created by this class >> loader, >> ???????? either by defining it directly or by delegation to another >> class loader. >> ???????? See . >> @@ -6964,21 +6964,22 @@ >> ?????? >> ???????? Return the name and the generic signature of the class >> indicated by klass. >> ????????

          >> -??????? If the class indicated by klass is a class or >> interface, then: >> +??????? If the class is a class or interface, then: >> ????????

            >> ????????
          • If the class or interface is not > id="../api/java.base/java/lang/Class.html#isHidden()">hi >> dden, >> -????????? then the returned name is > id="jni/types.html#type-signatures"> >> +????????? then the returned name is the > id="jni/types.html#type-signatures"> >> ?????????? JNI type signature. >> ?????????? For example, java.util.List is "Ljava/util/List;" >> ????????
            • >> ????????
          • If the class or interface is > id="../api/java.base/java/lang/Class.html#isHidden()">hidden >> , >> ?????????? then the returned name is a string of the form: >> ?????????? "L" + N + "." +? S + ";" >> -????????? where N is the binary name encoded in >> internal form >> +????????? where N is the binary name encoded in >> internal form (JVMS 4.2.1) >> ?????????? indicated by the class file passed to >> ?????????? > id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass, >> ?????????? and S is an unqualified name. >> -????????? The returned name is not a valid type descriptor. >> +????????? The returned name is not a type descriptor and does not >> conform to JVMS 4.3.2. >> +????????? For example, com.foo.Foo/AnySuffix is >> "Lcom/foo/Foo.AnySuffix;" >> ????????
            • >> ????????
          >> ????????

          >> @@ -12768,10 +12769,10 @@ >> ?????? A class or interface is created by one of the following: >> ??????

            >> ??????
          • By loading and deriving a class from a class >> file representation >> -????????? using class loader.
            • >> +????????? using a class loader. >> ??????
          • By invoking > id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass, >> ?????????? that creates a hidden class or interface from a >> class file representation.
            • >> -?????
          • By invoking methods in certain Java SE Platform API such >> as reflection.
            • >> +?????
          • By invoking methods in certain Java SE Platform APIs such >> as reflection.
            • >> ??????
          >> ??????

          >> ?????? Array class creation does not generate a class load event. >> diff --git >> a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >> b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >> >> --- >> a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >> +++ >> b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >> @@ -392,15 +392,15 @@ >> ????? * A class or interface creation can be triggered by one of the >> following: >> ????? *

            >> ????? *
          • by loading and deriving a class from a {@code class} file >> representation >> -???? *???? using class loader (see JVMS {@jvms 5.3}). >> +???? *???? using a class loader (see JVMS {@jvms 5.3}). >> ????? *
          • by invoking {@link >> java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], >> boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) >> -???? *???? Lookup::defineHiddenClass} that creates a {@link >> Class#isHidden >> +???? *???? Lookup::defineHiddenClass}, which creates a {@link >> Class#isHidden >> ????? *???? hidden class or interface} from a {@code class} file >> representation. >> ????? *
          • by invoking methods in certain reflection APIs such as >> ????? *???? {@link Class#forName(String) Class::forName}. >> ????? *
          >> ????? *

          >> -???? * An array class is created directly by Java virtual machine. >> An array >> +???? * An array class is created directly by the Java virtual >> machine.? Array >> ????? * class creation can be triggered by using class loaders or by >> invoking >> ????? * methods in certain reflection APIs such as >> ????? * {@link java.lang.reflect.Array#newInstance(Class, int) >> Array::newInstance} >> @@ -420,8 +420,8 @@ >> ????? * Returns an array of all classes which {@code loader} can find >> by name >> ????? * via {@link ClassLoader#loadClass(String, boolean) >> ClassLoader::loadClass}, >> ????? * {@link Class#forName(String) Class::forName} and bytecode >> linkage. >> -???? * That is, {@code loader} has been recorded as an initiating >> loader >> -???? * of these classes. If the supplied {@code loader} is {@code >> null}, >> +???? * That is, all classes for which {@code loader} has been >> recorded as >> +???? * an initiating loader. If the supplied {@code loader} is >> {@code null}, >> ????? * classes that the bootstrap class loader can find by name are >> returned. >> ????? * >> ????? *

          >> diff --git >> a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java >> b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java >> --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java >> +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java >> @@ -46,7 +46,7 @@ >> ????? * No ordering of this list guaranteed. >> ????? * The returned list will include all reference types, including >> ????? * {@link Class#isHidden hidden classes or interfaces}, loaded >> -???? * at least to the point of preparation and types (like array) >> +???? * at least to the point of preparation, and types (like array) >> ????? * for which preparation is not defined. >> ????? * >> ????? * @return a {@code List} of {@link ReferenceType} objects >> mirroring types >> @@ -59,8 +59,8 @@ >> ????? * Returns a list of all classes which this class loader >> ????? * can find by name via {@link ClassLoader#loadClass(String, >> boolean) >> ????? * ClassLoader::loadClass}, {@link Class#forName(String) >> Class::forName} >> -???? * and bytecode linkage in the target VM.? That is, this class >> loader >> -???? * has been recorded as an initiating loader of these classes. >> +???? * and bytecode linkage in the target VM.? That is, all classes for >> +???? * which this class loader has been recorded as an initiating >> loader. >> ????? *

          >> ????? * Each class in the returned list was created by this class loader >> ????? * either by defining it directly or by delegation to another >> class loader >> diff --git >> a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >> b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >> --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >> +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >> @@ -138,9 +138,9 @@ >> ????? * A class or interface creation can be triggered by one of the >> following: >> ????? *

            >> ????? *
          • by loading and deriving a class from a {@code class} file >> representation >> -???? *???? using class loader (see JVMS {@jvms 5.3}). >> +???? *???? using a class loader (see JVMS {@jvms 5.3}). >> ????? *
          • by invoking {@link >> java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], >> boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) >> -???? *???? Lookup::defineHiddenClass} that creates a {@link >> Class#isHidden >> +???? *???? Lookup::defineHiddenClass}, which creates a {@link >> Class#isHidden >> ????? *???? hidden class or interface} from a {@code class} file >> representation. >> ????? *
          • by invoking methods in certain reflection APIs such as >> ????? *???? {@link Class#forName(String) Class::forName}. >> >> Mandy >> >> > From chris.plummer at oracle.com Sat Apr 18 07:47:20 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 18 Apr 2020 00:47:20 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> Message-ID: Hi Mandy, Comments inline. On 4/17/20 4:52 PM, Mandy Chung wrote: > > > On 4/17/20 3:51 PM, Chris Plummer wrote: >> Hi Mandy, >> >> Thanks for updating the svc specs. Some comments below: >> >> >> In the JDWP spec update, you changed "JNI signature" to "type >> signature" in one place, but left it as "JNI signature" everywhere >> else. Should they all be changed? >> > > JDWP signature is changed because there is no JNI signature > representing a hidden class.??? I leave other references to JNI > signature as is since those only apply for normal classes as I wanted > to keep this change specifically due to hidden classes.? I think it's > good to file a JBS issue to follow up on JDWP and JDI to determine if > the spec should be upgraded to reference the new TypeDescriptor API. > >> >> In the JDWP spec for ClassLoaderReference.VisibleClasses: >> >> ?"That is, this class loader has been recorded as an >> initiating loader of the returned classes." -> "That is, all >> classes for which this class loader has been recorded as an >> initiating loader." >> >> This seems like too much detail to be put here. Basically the term >> "initiating ClassLoader" has turned into a short essay. Is it >> possible that all this detail could be put elsewhere and referenced? > > Any suggestion??? We attempted to place those description in JVM TI > Class section or ClassLoad event.?? However, that's not ideal place > since that's needed by JDWP, JDI and Instrumentation.?? I found > inlining this description is not ideal but it provides adequate > clarification. See other thread. > >> Aren't there other places in other specs where a similar >> clarification of "initiating ClassLoader" is needed (I see now that >> ClassLoaderClasses in the JVMTI spec, >> ClassLoaderReference,visibleClasses in the JDI spec, and >> Instrumentation.getInitiatedClasses are all dealing with this, but >> not all in the exact same way). >> > > I took the conservative side and make sure the clarification is in > place for all APIs.? I'm open to any suggestion for example having > JDWP and JDI to link to JVM TI spec if you think appropriate. > >> >> In the JVMTI spec for GetLoadedClasses: >> >> This suffers in a way similar to ClassLoaderReference.VisibleClasses >> in the JDWP spec, although not as badly. A simple concept ends up >> with a complex description, and it seems that description should >> really be in a more centralized place.? I would also suggest a bit of >> cleanup of these lines: >> >> 6866???????? An array class is created directly by Java virtual >> machine.? An array class >> 6867???????? creation can be triggered by using class loaders or by >> invoking methods in certain >> 6868???????? Java SE Platform API such as reflection. >> >> "Created by [the] Java virtual machine" (add "the") >> Change "An array class creation" to "The creation" since your are >> repeating "An array class" from the previous sentence. >> >> >> In the JVMTI spec ClassLoaderClasses section: >> >> "That is, initiating_loader has been recorded as an initiating loader >> of the returned classes." -> "That is, all classes for which >> initiating_loader has been recorded as an initiating loader." >> >> >> In the JVMTI spec GetClassSignature section: >> >> "If the class indicated by klass is ..." -> "If the class ..." (you >> just finished the previous sentence with "class indicated by Klass"). >> >> "the returned name is [the] JNI type signature" (add "the"). Also, is >> "JNI type signature" formally defined somewhere? This relates to my >> JDWP spec comment above. >> > > It's a link to > https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures. > This is how the current JVM TI spec defines. Since it looks like this reference was present before your changes, I guess it's ok to leave it, but like JDWP maybe a bug should be filed to clean it up. Regarding your JNI spec reference, it say "The JNI uses the Java VM?s representation of type signatures" and then has a table called "Java VM Type Signatures". No where in the JNI spec do you see "JNI Signature" or "JNI Type Signature". It seems we should always just use "Type Signature"? Even the JVMTI spec is not consistent. It has a couple of references to JNI Type Signature as links to the JNI spec, but also says "type signatures" in a couple of places, including for GetLocalVariableTable() which refers the the JVMS: "The local variable's type signature, encoded as a modified UTF-8 string. The signature format is the same as that defined in The Java? Virtual Machine Specification, Chapter 4.3.2. " > >> " where N is the binary name encoded in internal form indicated by >> the class file". Is "binary name encoded in internal form" explained >> somewhere? > > JVMS 4.2.1 > > https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.2.1 Thanks. I see you've also added a reference in your edits below. > >> Also, can you add an example of a returned hidden class signature? >> > OK > >> >> In the JVMTI spec ClassLoad section: >> >> "representation using [a] class loader" (add "a") >> >> "By invoking Lookup::defineHiddenClass, that creates ..."? -> "By >> invoking Lookup::defineHiddenClass to create ..." >> >> "certain Java SE Platform API" -> Should be "APIs" >> >> >> In JDI ClassLoaderReference.definedClasses() >> >> "loaded at least to the point of preparation and types ..." -> >> "loaded at least to the point of preparation, and types ..." (Note, >> this not a new issue with your edits) >> >> >> In Instrumentation.getAllLoadedClasses: >> >> The reference to `class` did not format properly. >> > > Serguei caught that one too.? I fixed it in my local repo. > >> "by invoking Lookup::defineHiddenClass that creates" -> "by invoking >> Lookup::defineHiddenClass, which creates" >> >> "An array class is created directly by Java virtual machine. An array >> class creation can be triggered ..." ->"An array class is created >> directly by the Java virtual machine. Array class creation can be >> triggered ..." >> >> >> In Instrumentation.getInitiatedClasses: >> >> "That is, loader has been recorded as an initiating loader of these >> classes." -> "That is, all classes for which loader has been recorded >> as an initiating loader." >> >> thanks, >> >> Chris > > Thanks for the review.?? See this patch of the editorial fixes. > > diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec > --- a/make/data/jdwp/jdwp.spec > +++ b/make/data/jdwp/jdwp.spec > @@ -2265,8 +2265,8 @@ > ???????? "Returns a list of all classes which this class loader can find " > ???????? "by name via ClassLoader::loadClass, " > ???????? "Class::forName and bytecode linkage. That is, " > -??????? "this class loader has been recorded as an initiating " > -??????? "loader of the returned classes. The list contains each > +??????? "all classes for which this class loader has been recorded as > an " > +??????? "initiating loader. The list contains each " > ???????? "reference type created by this loader and any types for which " > ???????? "loading was delegated by this class loader to another class > loader. " > ???????? "The list does not include hidden classes or interfaces > created by " > diff --git a/src/hotspot/share/prims/jvmti.xml > b/src/hotspot/share/prims/jvmti.xml > --- a/src/hotspot/share/prims/jvmti.xml > +++ b/src/hotspot/share/prims/jvmti.xml > @@ -6857,15 +6857,15 @@ > ???????? A class or interface creation can be triggered by one of the > following: > ????????
              > ????????
            • By loading and deriving a class from a class > file representation > -??????????? using class loader (see ).
              • > +??????????? using a class loader (see ). > ????????
            • By invoking id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass > ???????????? that creates a hidden class or interface from a > class file representation.
              • > -???????
            • By invoking methods in certain Java SE Platform API such > as reflection.
              • > +???????
            • By invoking methods in certain Java SE Platform APIs such > as reflection.
              • > ?????????
            > ????????

            > -??????? An array class is created directly by Java virtual machine.? > An array class > -??????? creation can be triggered by using class loaders or by > invoking methods in certain > -??????? Java SE Platform API such as reflection. > +??????? An array class is created directly by the Java virtual > machine.? The creation > +??????? can be triggered by using class loaders or by invoking > methods in certain > +??????? Java SE Platform APIs such as reflection. > ????????

            > ???????? The returned list includes all classes and interfaces, including > ???????? id="../api/java.base/java/lang/Class.html#isHidden()"> > @@ -6904,8 +6904,8 @@ > ???????? can find by name via > ???????? id="../api/java.base/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean)">ClassLoader::loadClass, > ???????? id="../api/java.base/java/lang/Class.html#forName(java.lang.String,boolean,java.lang.ClassLoader)">Class::forName > and bytecode linkage. > -??????? That is, initiating_loader > -??????? has been recorded as an initiating loader of the returned > classes. > +??????? That is, all classes for which initiating_loader > +??????? has been recorded as an initiating loader. > ???????? Each class in the returned array was created by this class > loader, > ???????? either by defining it directly or by delegation to another > class loader. > ???????? See . > @@ -6964,21 +6964,22 @@ > ?????? > ???????? Return the name and the generic signature of the class > indicated by klass. > ????????

            > -??????? If the class indicated by klass is a class or > interface, then: > +??????? If the class is a class or interface, then: > ????????

              > ????????
            • If the class or interface is not id="../api/java.base/java/lang/Class.html#isHidden()">hi > dden, > -????????? then the returned name is id="jni/types.html#type-signatures"> > +????????? then the returned name is the id="jni/types.html#type-signatures"> > ?????????? JNI type signature. > ?????????? For example, java.util.List is "Ljava/util/List;" > ????????
              • > ????????
            • If the class or interface is id="../api/java.base/java/lang/Class.html#isHidden()">hidden > , > ?????????? then the returned name is a string of the form: > ?????????? "L" + N + "." +? S + ";" > -????????? where N is the binary name encoded in internal > form > +????????? where N is the binary name encoded in internal > form (JVMS 4.2.1) > ?????????? indicated by the class file passed to > ?????????? id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass, > ?????????? and S is an unqualified name. > -????????? The returned name is not a valid type descriptor. > +????????? The returned name is not a type descriptor and does not > conform to JVMS 4.3.2. > +????????? For example, com.foo.Foo/AnySuffix is "Lcom/foo/Foo.AnySuffix;" > ????????
              • > ????????
            > ????????

            > @@ -12768,10 +12769,10 @@ > ?????? A class or interface is created by one of the following: > ??????

              > ??????
            • By loading and deriving a class from a class > file representation > -????????? using class loader.
              • > +????????? using a class loader. > ??????
            • By invoking id="../api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)">Lookup::defineHiddenClass, > ?????????? that creates a hidden class or interface from a > class file representation.
              • > -?????
            • By invoking methods in certain Java SE Platform API such as > reflection.
              • > +?????
            • By invoking methods in certain Java SE Platform APIs such > as reflection.
              • > ??????
            > ??????

            > ?????? Array class creation does not generate a class load event. > diff --git > a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > --- > a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > +++ > b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > @@ -392,15 +392,15 @@ > ????? * A class or interface creation can be triggered by one of the > following: > ????? *

              > ????? *
            • by loading and deriving a class from a {@code class} file > representation > -???? *???? using class loader (see JVMS {@jvms 5.3}). > +???? *???? using a class loader (see JVMS {@jvms 5.3}). > ????? *
            • by invoking {@link > java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], > boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) > -???? *???? Lookup::defineHiddenClass} that creates a {@link > Class#isHidden > +???? *???? Lookup::defineHiddenClass}, which creates a {@link > Class#isHidden > ????? *???? hidden class or interface} from a {@code class} file > representation. > ????? *
            • by invoking methods in certain reflection APIs such as > ????? *???? {@link Class#forName(String) Class::forName}. > ????? *
            > ????? *

            > -???? * An array class is created directly by Java virtual machine.? > An array > +???? * An array class is created directly by the Java virtual > machine.? Array > ????? * class creation can be triggered by using class loaders or by > invoking > ????? * methods in certain reflection APIs such as > ????? * {@link java.lang.reflect.Array#newInstance(Class, int) > Array::newInstance} > @@ -420,8 +420,8 @@ > ????? * Returns an array of all classes which {@code loader} can find > by name > ????? * via {@link ClassLoader#loadClass(String, boolean) > ClassLoader::loadClass}, > ????? * {@link Class#forName(String) Class::forName} and bytecode linkage. > -???? * That is, {@code loader} has been recorded as an initiating loader > -???? * of these classes. If the supplied {@code loader} is {@code null}, > +???? * That is, all classes for which {@code loader} has been recorded as > +???? * an initiating loader. If the supplied {@code loader} is {@code > null}, > ????? * classes that the bootstrap class loader can find by name are > returned. > ????? * > ????? *

            > diff --git > a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > @@ -46,7 +46,7 @@ > ????? * No ordering of this list guaranteed. > ????? * The returned list will include all reference types, including > ????? * {@link Class#isHidden hidden classes or interfaces}, loaded > -???? * at least to the point of preparation and types (like array) > +???? * at least to the point of preparation, and types (like array) > ????? * for which preparation is not defined. > ????? * > ????? * @return a {@code List} of {@link ReferenceType} objects > mirroring types > @@ -59,8 +59,8 @@ > ????? * Returns a list of all classes which this class loader > ????? * can find by name via {@link ClassLoader#loadClass(String, boolean) > ????? * ClassLoader::loadClass}, {@link Class#forName(String) > Class::forName} > -???? * and bytecode linkage in the target VM.? That is, this class loader > -???? * has been recorded as an initiating loader of these classes. > +???? * and bytecode linkage in the target VM.? That is, all classes for > +???? * which this class loader has been recorded as an initiating loader. > ????? *

            > ????? * Each class in the returned list was created by this class loader > ????? * either by defining it directly or by delegation to another > class loader > diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > @@ -138,9 +138,9 @@ > ????? * A class or interface creation can be triggered by one of the > following: > ????? *

              > ????? *
            • by loading and deriving a class from a {@code class} file > representation > -???? *???? using class loader (see JVMS {@jvms 5.3}). > +???? *???? using a class loader (see JVMS {@jvms 5.3}). > ????? *
            • by invoking {@link > java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], > boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) > -???? *???? Lookup::defineHiddenClass} that creates a {@link > Class#isHidden > +???? *???? Lookup::defineHiddenClass}, which creates a {@link > Class#isHidden > ????? *???? hidden class or interface} from a {@code class} file > representation. > ????? *
            • by invoking methods in certain reflection APIs such as > ????? *???? {@link Class#forName(String) Class::forName}. > Above changes all look good. thanks, Chris > Mandy > > From david.holmes at oracle.com Sat Apr 18 13:56:16 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 18 Apr 2020 23:56:16 +1000 Subject: RFR: 8231585: java/lang/management/ThreadMXBean/MaxDepthForThreadInfoTest.java fails with java.lang.NullPointerException In-Reply-To: <902A52FD-B44F-47C3-8658-969D0CEA2671@oracle.com> References: <902A52FD-B44F-47C3-8658-969D0CEA2671@oracle.com> Message-ID: <7287552a-4e6b-9a7b-991a-05db515a49cc@oracle.com> Hi Daniil, On 18/04/2020 6:03 am, Daniil Titov wrote: > Please review the change that fixes intermittent failure of java/lang/management/ThreadMXBean/MaxDepthForThreadInfoTest.java > > As David noticed (thank you, David, for this analysis) there is no guarantee that all threads found by getAllThreadIds() are still alive by the time we call getThreadInfo() so we have to allow for null array entries. > > Testing: Mach5 tests with Graal on passed 300 times. Fix looks good - thanks. I think it would be informative to actually determine which thread(s) is disappearing (not as part of the test just as some diagnostic info to add to the JBS issue). Can you reproduce the failure easily? Thanks, David > [1] http://cr.openjdk.java.net/~dtitov/8231585/webrev.01/ > [2] https://bugs.openjdk.java.net/browse/JDK-8231585 > > Best regards, > Daniil > > From daniil.x.titov at oracle.com Sat Apr 18 18:30:41 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Sat, 18 Apr 2020 11:30:41 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same Message-ID: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> Please review the change that fixes the failure of javax/management/generified/GenericTest.java and javax/management/query/CustomQueryTest.java tests when Graal is on. The tests checks that calls of management API are consistent and return the same set of MBeans. However, when Graal is on the Graal MBean might be registered between the calls that in turn makes the results inconsistent and the tests fail. The fix makes the test aware that some MBean might be registered while the checks run and if it happens the tests repeat the check. Testing : Mach5 tests with Graal on and tier1-tier3 tests passed. [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8242239 Thanks, Daniil From mandy.chung at oracle.com Sat Apr 18 21:09:57 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 18 Apr 2020 14:09:57 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> Message-ID: <4f9a5a74-3b10-3dee-e055-feef32191c5d@oracle.com> On 4/18/20 12:47 AM, Chris Plummer wrote: >> >> It's a link to >> https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures. >> This is how the current JVM TI spec defines. > Since it looks like this reference was present before your changes, I > guess it's ok to leave it, but like JDWP maybe a bug should be filed > to clean it up. > Right, they are existing reference.? I'll let Serguei to file a JBS issue to follow up. > Regarding your JNI spec reference, it say "The JNI uses the Java VM?s > representation of type signatures" and then has a table called "Java > VM Type Signatures". No where in the JNI spec do you see "JNI > Signature" or "JNI Type Signature". It seems we should always just use > "Type Signature"? > I agree that the svc specs should be examined and use the terminologies consistently. > Even the JVMTI spec is not consistent. It has a couple of references > to JNI Type Signature as links to the JNI spec, but also says "type > signatures" in a couple of places, including for > GetLocalVariableTable() which refers the the JVMS: "The local > variable's type signature, encoded as a modified UTF-8 string. The > signature format is the same as that defined in The Java? Virtual > Machine Specification, Chapter 4.3.2. " Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Sat Apr 18 22:28:52 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 18 Apr 2020 15:28:52 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <9b74fc5f-0cb0-e0f5-6a36-969db3deff0a@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> <9b74fc5f-0cb0-e0f5-6a36-969db3deff0a@oracle.com> Message-ID: <358b4e34-66e7-6ae3-82f3-5c5d9bf77333@oracle.com> Hi Chris, Serguei, On 4/18/20 12:18 AM, Chris Plummer wrote: > > Yes. I'd like to see all this as part of the Class/Classloading spec > in some sort of section that gives an overview of all these topics, > but mostly clarifies what an initiating loader is, and the (non) > relationship to hidden classes. We should refer initiating loader and class loading from JVMS 5.3. JVM TI needs the clarification w.r.t.? GetClassLoaderClasses that does not include hidden classes because the initiating class loader cannot find it. GetLoadedClasses is about class creation.?? While it seems tempted to put the descriptions in some sort of overview section, I found the clarification is specific for each function and hence inlining them in each function helps the readers directly see the difference. I made a few changes that should ease your concern of duplication: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes.01/ - The class creation description added in GetLoadedClasses.? Not in JDWP, JDI and Instrumentation. - The description in GetClassLoaderClasses, Instrumentation::getInitiatedClasses, ClassLoaderReference::visibleClasses is revised to take out the details.?? Add links from JDWP and JDI to GetClassLoaderClasses. - The details about hidden classes can be found from `Class::isHidden` and? ??? `Lookup::defineHiddenClass`. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From suenaga at oss.nttdata.com Mon Apr 20 00:32:34 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 20 Apr 2020 09:32:34 +0900 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: <056ba00d-4e1e-f48e-6d7e-10d026b0d2a6@oracle.com> References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> <056ba00d-4e1e-f48e-6d7e-10d026b0d2a6@oracle.com> Message-ID: <5a496dbd-abf9-0811-bb93-f35800396479@oss.nttdata.com> Hi all, Could you review it? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ I need one more reviewer to push. Thanks, Yasumasa On 2020/04/17 5:13, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > Thank you for the update. > It looks good. > > Thanks, > Serguei > > > On 4/10/20 04:30, Yasumasa Suenaga wrote: >> Hi Serguei, >> >> I use current_jt in this webrev. Could you review again? >> >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ >> >> I tested this change with vmTestbase/nsk/jvmti, they are fine on my Linux x64. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/10 17:21, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> Thank you for the update. >>> >>> Minor: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/src/hotspot/share/prims/jvmtiEnvBase.cpp.udiff.html >>> >>> + err = get_locked_objects_in_frame(JavaThread::current(), java_thread, jvf, owned_monitors_list, depth-1); . . . >>> >>> + JvmtiMonitorClosure jmc(java_thread, JavaThread::current(), owned_monitors_list, this); >>> >>> You can use current_jt instead of JavaThread::current() above. >>> >>> There is also some test coverage in the vmTestbase/nsk/jvmti/scenarios tests. >>> This one as well: >>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest >>> Probably it is easier to run all vmTestbase/nsk/jvmti tests. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/10/20 01:05, Yasumasa Suenaga wrote: >>>> Hi Serguei, >>>> >>>> Thanks for your comment! >>>> I uploaded new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/ >>>> >>>> I ran following tests, and all of them were passed on my Linux x64. >>>> >>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>> ?- vmTestbase/nsk/jdi >>>> ?- vmTestbase/nsk/jdwp >>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>> ?- serviceability/jdwp >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/04/10 14:50, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa, >>>>> >>>>> It looks pretty good in general. >>>>> A couple of comments though. >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html >>>>> >>>>> 650 JvmtiEnvBase::get_current_contended_monitor(JavaThread *java_thread, jobject *monitor_ptr) { >>>>> 651 assert(!Thread::current()->is_VM_thread() && >>>>> 652 (Thread::current() == java_thread || >>>>> 653 Thread::current() == java_thread->active_handshaker()), >>>>> 654 "call by myself or at direct handshake"); >>>>> >>>>> ? ... >>>>> >>>>> 685 JvmtiEnvBase::get_owned_monitors(JavaThread* java_thread, >>>>> ? 686 GrowableArray *owned_monitors_list) { >>>>> ? 687?? jvmtiError err = JVMTI_ERROR_NONE; >>>>> 688 assert(!Thread::current()->is_VM_thread() && >>>>> 689 (Thread::current() == java_thread || >>>>> 690 Thread::current() == java_thread->active_handshaker()), >>>>> 691 "call by myself or at direct handshake"); >>>>> >>>>> I'd suggest to add this at the beginning: >>>>> ?? JavaThread *current_jt = JavaThread::current(); >>>>> >>>>> >>>>> 676 JavaThread *current_jt = reinterpret_cast(JavaThread::current()); >>>>> >>>>> There is not need in reinterpret_cast. Also, you can use the current_jt defined above. >>>>> >>>>> Also, please, removed these two definitions as they became unused with your fix: >>>>> ??? src/hotspot/share/runtime/vmOperations.hpp: template(GGetCurrentContendedMonitoretOwnedMonitorInfo) \ >>>>> ??? src/hotspot/share/runtime/vmOperations.hpp: template()??????????? \ >>>>> >>>>> The impacted JVMTI monitor functions are used in the JDWP agent to support the JDI ThreadReference implementation. >>>>> To be safe the JDI & JDWP tests have to be run as well. It is well covered by the tier-5. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 4/9/20 21:46, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this change: >>>>>> >>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >>>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/ >>>>>> >>>>>> We've discussed to use Thread-Local Handshake in some JVMTI functions [1]. >>>>>> This change is for monitor functions. It affects GetOwnedMonitorInfo(), GetOwnedMonitorStackDepthInfo(), GetCurrentContendedMonitor(). >>>>>> >>>>>> It passed tests on submit repo (mach5-one-ysuenaga-JDK-8242425-20200410-0228-10075639), and also I confirmed to pass following tests: >>>>>> >>>>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html >>>>> >>> > From david.holmes at oracle.com Mon Apr 20 02:29:54 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Apr 2020 12:29:54 +1000 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: <5a496dbd-abf9-0811-bb93-f35800396479@oss.nttdata.com> References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> <056ba00d-4e1e-f48e-6d7e-10d026b0d2a6@oracle.com> <5a496dbd-abf9-0811-bb93-f35800396479@oss.nttdata.com> Message-ID: <14cb9316-9b20-a99b-9614-e49426474ab7@oracle.com> Hi Yasumasa, This looks good. A couple of minor nits below. On 20/04/2020 10:32 am, Yasumasa Suenaga wrote: > Hi all, > > Could you review it? > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ src/hotspot/share/prims/jvmtiEnvBase.hpp This comment needs expanding now: 295 // JVMTI API helper functions which are called at safepoint or thread is suspended. Can you fix up the indentation here please: 304 jvmtiError get_current_contended_monitor(JavaThread *java_thread, 305 jobject *monitor_ptr); 306 jvmtiError get_owned_monitors(JavaThread* java_thread, 307 GrowableArray *owned_monitors_list); the second lines should line up with the J in JavaThread. Could you put the initializers on a separate line each please: 388 : HandshakeClosure("GetOwnedMonitorInfo"), 389 _env(env), _result(JVMTI_ERROR_NONE), _owned_monitors_list(owned_monitor_list) {} Similarly for: 428 : HandshakeClosure("GetOneCurrentContendedMonitor"), 429 _env(env), _owned_monitor_ptr(mon_ptr), 430 _result(JVMTI_ERROR_THREAD_NOT_ALIVE) {} --- No need for updated webrev. Thanks, David ----- > I need one more reviewer to push. > > > Thanks, > > Yasumasa > > > On 2020/04/17 5:13, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> Thank you for the update. >> It looks good. >> >> Thanks, >> Serguei >> >> >> On 4/10/20 04:30, Yasumasa Suenaga wrote: >>> Hi Serguei, >>> >>> I use current_jt in this webrev. Could you review again? >>> >>> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ >>> >>> I tested this change with vmTestbase/nsk/jvmti, they are fine on my >>> Linux x64. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/04/10 17:21, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> Thank you for the update. >>>> >>>> Minor: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/src/hotspot/share/prims/jvmtiEnvBase.cpp.udiff.html >>>> >>>> >>>> + err = get_locked_objects_in_frame(JavaThread::current(), >>>> java_thread, jvf, owned_monitors_list, depth-1); . . . >>>> >>>> + JvmtiMonitorClosure jmc(java_thread, JavaThread::current(), >>>> owned_monitors_list, this); >>>> >>>> You can use current_jt instead of JavaThread::current() above. >>>> >>>> There is also some test coverage in the >>>> vmTestbase/nsk/jvmti/scenarios tests. >>>> This one as well: >>>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest >>>> >>>> Probably it is easier to run all vmTestbase/nsk/jvmti tests. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/10/20 01:05, Yasumasa Suenaga wrote: >>>>> Hi Serguei, >>>>> >>>>> Thanks for your comment! >>>>> I uploaded new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/ >>>>> >>>>> I ran following tests, and all of them were passed on my Linux x64. >>>>> >>>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>> ?- vmTestbase/nsk/jdi >>>>> ?- vmTestbase/nsk/jdwp >>>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>> ?- serviceability/jdwp >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2020/04/10 14:50, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> It looks pretty good in general. >>>>>> A couple of comments though. >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html >>>>>> >>>>>> >>>>>> 650 JvmtiEnvBase::get_current_contended_monitor(JavaThread >>>>>> *java_thread, jobject *monitor_ptr) { >>>>>> 651 assert(!Thread::current()->is_VM_thread() && >>>>>> 652 (Thread::current() == java_thread || >>>>>> 653 Thread::current() == java_thread->active_handshaker()), >>>>>> 654 "call by myself or at direct handshake"); >>>>>> >>>>>> ? ... >>>>>> >>>>>> 685 JvmtiEnvBase::get_owned_monitors(JavaThread* java_thread, >>>>>> ? 686 GrowableArray >>>>>> *owned_monitors_list) { >>>>>> ? 687?? jvmtiError err = JVMTI_ERROR_NONE; >>>>>> 688 assert(!Thread::current()->is_VM_thread() && >>>>>> 689 (Thread::current() == java_thread || >>>>>> 690 Thread::current() == java_thread->active_handshaker()), >>>>>> 691 "call by myself or at direct handshake"); >>>>>> >>>>>> I'd suggest to add this at the beginning: >>>>>> ?? JavaThread *current_jt = JavaThread::current(); >>>>>> >>>>>> >>>>>> 676 JavaThread *current_jt = reinterpret_cast>>>>> *>(JavaThread::current()); >>>>>> >>>>>> There is not need in reinterpret_cast. Also, you can >>>>>> use the current_jt defined above. >>>>>> >>>>>> Also, please, removed these two definitions as they became unused >>>>>> with your fix: >>>>>> ??? src/hotspot/share/runtime/vmOperations.hpp: >>>>>> template(GGetCurrentContendedMonitoretOwnedMonitorInfo) \ >>>>>> ??? src/hotspot/share/runtime/vmOperations.hpp: >>>>>> template()??????????? \ >>>>>> >>>>>> The impacted JVMTI monitor functions are used in the JDWP agent to >>>>>> support the JDI ThreadReference implementation. >>>>>> To be safe the JDI & JDWP tests have to be run as well. It is well >>>>>> covered by the tier-5. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 4/9/20 21:46, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this change: >>>>>>> >>>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >>>>>>> ? webrev: >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/ >>>>>>> >>>>>>> We've discussed to use Thread-Local Handshake in some JVMTI >>>>>>> functions [1]. >>>>>>> This change is for monitor functions. It affects >>>>>>> GetOwnedMonitorInfo(), GetOwnedMonitorStackDepthInfo(), >>>>>>> GetCurrentContendedMonitor(). >>>>>>> >>>>>>> It passed tests on submit repo >>>>>>> (mach5-one-ysuenaga-JDK-8242425-20200410-0228-10075639), and also >>>>>>> I confirmed to pass following tests: >>>>>>> >>>>>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>>>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html >>>>>>> >>>>>> >>>> >> From ralf.schmelter at sap.com Mon Apr 20 08:13:43 2020 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Mon, 20 Apr 2020 08:13:43 +0000 Subject: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump In-Reply-To: References: <01361a9d-2855-db67-a176-73731fada08f@oracle.com> <0c687e55-ed91-e606-28a7-f9aef745ed8d@oracle.com> <490d58f7-7adc-00aa-b504-0ac284fe7eb5@oracle.com> <0343dfac-61f7-1b1c-ee96-bdee130578ad@oracle.com> Message-ID: Hi Richard, thanks for the review. I have incorporated your remarks into a new webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.2/ Some remarks to specific points: > ### src/hotspot/share/services/heapDumper.cpp > 762: assert(_active, "Must be active"); > > It appears to me that the assertion would fail, if an error occurred creating the CompressionBackend. You are supposed to check for errors after creating the DumpWriter (which creates the CompressionBackend). And in case of an error, you directly destruct the object. I've added a comment to make that clear. > 767: I think _current->in_used doesn't take the final 9 bytes into account that are written in > DumperSupport::end_of_dump() after the last dump segment has been finished. > You could call get_new_buffer() instead of the if clause. Wow, how did you found this? I've fixed it by making sure we flush the DumpWriter before calling the deactivate method. > 1064: DumpWriter::DumpWriter() > > There doesn't seem to be enough error handling if _buffer cannot be allocated. > E.g. DumpWriter::write_raw() at line 1091 will enter an endless loop. As described above, this will not happen if we check for error after constructing the DumpWriter. > ### src/java.base/share/native/libzip/zip_util.c > 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() performance wise. But have you > measured the performance gain? In other words: is it worth it? :) This is not done for performance, but to make sure the allocation will not fail midway during writing the dump. Maybe it is not worth it, though. > 1655: The result of deflateBound() seems to depend on the header comment, which is not given > here. Could this be an issue, because ZIP_GZip_Fully() can take a comment? I've added a 1024 byte additional bytes to avoid the problem. > ### test/lib/jdk/test/lib/hprof/parser/Reader.java > > 93: is the created GzipRandomAccess instance closed somewhere? The object is not closed since it is still used by the Snapshot returned. Best regard, Ralf -----Original Message----- From: Reingruber, Richard Sent: Tuesday, 14 April 2020 10:30 To: Schmelter, Ralf ; Ioi Lam ; Langer, Christoph ; Yasumasa Suenaga ; serguei.spitsyn at oracle.com; hotspot-runtime-dev at openjdk.java.net runtime Cc: serviceability-dev at openjdk.java.net Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump Hi Ralf, thanks for providing this enhancement to parallel gzip-compress heap dumps! I reckon it's safe to say that the coding is sophisticated. It would be awesome if you could sketch the idea of how HeapDumper, DumpWriter and CompressionBackend work together to produce the gzipped dump in a source code comment. Just enough to get started if somebody should ever have to track down a bug -- an unlikely event, I know ;) Please find the details of my review below. Thanks, Richard. // Not Reviewer -- ### src/hotspot/share/services/diagnosticCommand.cpp 510 _gzip_level("-gz-level", "The compression level from 0 (store) to 9 (best) when writing in gzipped format.", 511 "INT", "FALSE", "1") { "FALSE" should be probably false. ### src/hotspot/share/services/diagnosticCommand.hpp Ok. ### src/hotspot/share/services/heapDumper.cpp 390: Typo: initized 415: Typo: GZipComressor 477: Could you please add a comment, how the "HPROF BLOCKSIZE" comment is helpful? 539: Member variables of WriteWork are missing the '_' prefix. 546: Just a comment: WriteWork::in_max is actually a compile time constant. Would be nice if it could be declared so. One could use templates for this, but then my favourite ide (eclipse cdt) doesn't show me references and call hierarchies anymore. So I don't think it is worth it. 591: Typo: Removes the first element. Returns NULL is empty. 663: _writer, _compressor, _lock could be const. 762: assert(_active, "Must be active"); It appears to me that the assertion would fail, if an error occurred creating the CompressionBackend. 767: I think _current->in_used doesn't take the final 9 bytes into account that are written in DumperSupport::end_of_dump() after the last dump segment has been finished. You could call get_new_buffer() instead of the if clause. 903: Typo: Check if we don not waste more than _max_waste 1064: DumpWriter::DumpWriter() There doesn't seem to be enough error handling if _buffer cannot be allocated. E.g. DumpWriter::write_raw() at line 1091 will enter an endless loop. 2409: A comment, why Shenandoah is not supported, would be good. In general I'd say it is good and natural to use the GC work threads. ### src/hotspot/share/services/heapDumper.hpp Ok. ### src/java.base/share/native/libzip/zip_util.c I'm not familiar with zlib, but here are my .02? :) 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() performance wise. But have you measured the performance gain? In other words: is it worth it? :) 1655: The result of deflateBound() seems to depend on the header comment, which is not given here. Could this be an issue, because ZIP_GZip_Fully() can take a comment? 1658: deflateEnd() should not be called if deflateInit2Wrapper() failed. I think this can lead otherwise to a double free() call. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java 66: Maybe additionally check the exit value? 73: It's unclear to me, why this fails. Because the dump already exists? Because the level is invalid? Reading the comment I'd expect success, not failure. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestEpsilon.java Ok. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestShenandoah.java Ok. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestZ.java Ok. ### test/lib/jdk/test/lib/hprof/parser/GzipRandomAccess.java Ok. ### test/lib/jdk/test/lib/hprof/parser/HprofReader.java Ok. ### test/lib/jdk/test/lib/hprof/parser/Reader.java 93: is the created GzipRandomAccess instance closed somewhere? From richard.reingruber at sap.com Mon Apr 20 10:12:34 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Mon, 20 Apr 2020 10:12:34 +0000 Subject: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump In-Reply-To: References: <01361a9d-2855-db67-a176-73731fada08f@oracle.com> <0c687e55-ed91-e606-28a7-f9aef745ed8d@oracle.com> <490d58f7-7adc-00aa-b504-0ac284fe7eb5@oracle.com> <0343dfac-61f7-1b1c-ee96-bdee130578ad@oracle.com> Message-ID: Hi Ralf, > > 767: I think _current->in_used doesn't take the final 9 bytes into account that are written in > > DumperSupport::end_of_dump() after the last dump segment has been finished. > > You could call get_new_buffer() instead of the if clause. > Wow, how did you found this? I've fixed it by making sure we flush the DumpWriter before calling the deactivate method. Spending long hours on the review ;) Ok with the fix. > > ### src/java.base/share/native/libzip/zip_util.c > > 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() performance wise. But have you > > measured the performance gain? In other words: is it worth it? :) > This is not done for performance, but to make sure the allocation will not fail midway during writing the dump. Maybe it is not worth it, though. Understood. The heap dump will succeed if you can allocate at least one WriteWork instance. Without that you could get out of memory errors in the zlib which would make the dump fail. Ok! > http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.2/ Thanks for the clarifications and the changes in the new webrev. Webrev.2 looks good to me. Cheers, Richard. -----Original Message----- From: Schmelter, Ralf Sent: Montag, 20. April 2020 10:14 To: Reingruber, Richard ; Ioi Lam ; Langer, Christoph ; Yasumasa Suenaga ; serguei.spitsyn at oracle.com; hotspot-runtime-dev at openjdk.java.net runtime Cc: serviceability-dev at openjdk.java.net Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump Hi Richard, thanks for the review. I have incorporated your remarks into a new webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.2/ Some remarks to specific points: > ### src/hotspot/share/services/heapDumper.cpp > 762: assert(_active, "Must be active"); > > It appears to me that the assertion would fail, if an error occurred creating the CompressionBackend. You are supposed to check for errors after creating the DumpWriter (which creates the CompressionBackend). And in case of an error, you directly destruct the object. I've added a comment to make that clear. > 767: I think _current->in_used doesn't take the final 9 bytes into account that are written in > DumperSupport::end_of_dump() after the last dump segment has been finished. > You could call get_new_buffer() instead of the if clause. Wow, how did you found this? I've fixed it by making sure we flush the DumpWriter before calling the deactivate method. > 1064: DumpWriter::DumpWriter() > > There doesn't seem to be enough error handling if _buffer cannot be allocated. > E.g. DumpWriter::write_raw() at line 1091 will enter an endless loop. As described above, this will not happen if we check for error after constructing the DumpWriter. > ### src/java.base/share/native/libzip/zip_util.c > 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() performance wise. But have you > measured the performance gain? In other words: is it worth it? :) This is not done for performance, but to make sure the allocation will not fail midway during writing the dump. Maybe it is not worth it, though. > 1655: The result of deflateBound() seems to depend on the header comment, which is not given > here. Could this be an issue, because ZIP_GZip_Fully() can take a comment? I've added a 1024 byte additional bytes to avoid the problem. > ### test/lib/jdk/test/lib/hprof/parser/Reader.java > > 93: is the created GzipRandomAccess instance closed somewhere? The object is not closed since it is still used by the Snapshot returned. Best regard, Ralf -----Original Message----- From: Reingruber, Richard Sent: Tuesday, 14 April 2020 10:30 To: Schmelter, Ralf ; Ioi Lam ; Langer, Christoph ; Yasumasa Suenaga ; serguei.spitsyn at oracle.com; hotspot-runtime-dev at openjdk.java.net runtime Cc: serviceability-dev at openjdk.java.net Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump Hi Ralf, thanks for providing this enhancement to parallel gzip-compress heap dumps! I reckon it's safe to say that the coding is sophisticated. It would be awesome if you could sketch the idea of how HeapDumper, DumpWriter and CompressionBackend work together to produce the gzipped dump in a source code comment. Just enough to get started if somebody should ever have to track down a bug -- an unlikely event, I know ;) Please find the details of my review below. Thanks, Richard. // Not Reviewer -- ### src/hotspot/share/services/diagnosticCommand.cpp 510 _gzip_level("-gz-level", "The compression level from 0 (store) to 9 (best) when writing in gzipped format.", 511 "INT", "FALSE", "1") { "FALSE" should be probably false. ### src/hotspot/share/services/diagnosticCommand.hpp Ok. ### src/hotspot/share/services/heapDumper.cpp 390: Typo: initized 415: Typo: GZipComressor 477: Could you please add a comment, how the "HPROF BLOCKSIZE" comment is helpful? 539: Member variables of WriteWork are missing the '_' prefix. 546: Just a comment: WriteWork::in_max is actually a compile time constant. Would be nice if it could be declared so. One could use templates for this, but then my favourite ide (eclipse cdt) doesn't show me references and call hierarchies anymore. So I don't think it is worth it. 591: Typo: Removes the first element. Returns NULL is empty. 663: _writer, _compressor, _lock could be const. 762: assert(_active, "Must be active"); It appears to me that the assertion would fail, if an error occurred creating the CompressionBackend. 767: I think _current->in_used doesn't take the final 9 bytes into account that are written in DumperSupport::end_of_dump() after the last dump segment has been finished. You could call get_new_buffer() instead of the if clause. 903: Typo: Check if we don not waste more than _max_waste 1064: DumpWriter::DumpWriter() There doesn't seem to be enough error handling if _buffer cannot be allocated. E.g. DumpWriter::write_raw() at line 1091 will enter an endless loop. 2409: A comment, why Shenandoah is not supported, would be good. In general I'd say it is good and natural to use the GC work threads. ### src/hotspot/share/services/heapDumper.hpp Ok. ### src/java.base/share/native/libzip/zip_util.c I'm not familiar with zlib, but here are my .02? :) 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() performance wise. But have you measured the performance gain? In other words: is it worth it? :) 1655: The result of deflateBound() seems to depend on the header comment, which is not given here. Could this be an issue, because ZIP_GZip_Fully() can take a comment? 1658: deflateEnd() should not be called if deflateInit2Wrapper() failed. I think this can lead otherwise to a double free() call. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java 66: Maybe additionally check the exit value? 73: It's unclear to me, why this fails. Because the dump already exists? Because the level is invalid? Reading the comment I'd expect success, not failure. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestEpsilon.java Ok. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestShenandoah.java Ok. ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestZ.java Ok. ### test/lib/jdk/test/lib/hprof/parser/GzipRandomAccess.java Ok. ### test/lib/jdk/test/lib/hprof/parser/HprofReader.java Ok. ### test/lib/jdk/test/lib/hprof/parser/Reader.java 93: is the created GzipRandomAccess instance closed somewhere? From coleen.phillimore at oracle.com Mon Apr 20 12:12:54 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 20 Apr 2020 08:12:54 -0400 Subject: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump In-Reply-To: References: <0343dfac-61f7-1b1c-ee96-bdee130578ad@oracle.com> Message-ID: <2363c58d-38c1-ae19-ed34-c82af6304780@oracle.com> Hi, I don't want to review this but could you put this new code in its own file?? heapDumper only needs CompressionBackend to be exported, from what I can tell. Thanks, Coleen On 4/20/20 6:12 AM, Reingruber, Richard wrote: > Hi Ralf, > >>> 767: I think _current->in_used doesn't take the final 9 bytes into account that are written in >>> DumperSupport::end_of_dump() after the last dump segment has been finished. >>> You could call get_new_buffer() instead of the if clause. >> Wow, how did you found this? I've fixed it by making sure we flush the DumpWriter before calling the deactivate method. > Spending long hours on the review ;) > Ok with the fix. > >>> ### src/java.base/share/native/libzip/zip_util.c >>> 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() performance wise. But have you >>> measured the performance gain? In other words: is it worth it? :) >> This is not done for performance, but to make sure the allocation will not fail midway during writing the dump. Maybe it is not worth it, though. > Understood. The heap dump will succeed if you can allocate at least one WriteWork instance. Without > that you could get out of memory errors in the zlib which would make the dump fail. Ok! > >> http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.2/ > Thanks for the clarifications and the changes in the new webrev. > Webrev.2 looks good to me. > > Cheers, Richard. > > -----Original Message----- > From: Schmelter, Ralf > Sent: Montag, 20. April 2020 10:14 > To: Reingruber, Richard ; Ioi Lam ; Langer, Christoph ; Yasumasa Suenaga ; serguei.spitsyn at oracle.com; hotspot-runtime-dev at openjdk.java.net runtime > Cc: serviceability-dev at openjdk.java.net > Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump > > Hi Richard, > > thanks for the review. I have incorporated your remarks into a new webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.2/ > > Some remarks to specific points: > >> ### src/hotspot/share/services/heapDumper.cpp >> 762: assert(_active, "Must be active"); >> >> It appears to me that the assertion would fail, if an error occurred creating the CompressionBackend. > You are supposed to check for errors after creating the DumpWriter (which creates the CompressionBackend). And in case of an error, you directly destruct the object. I've added a comment to make that clear. > >> 767: I think _current->in_used doesn't take the final 9 bytes into account that are written in >> DumperSupport::end_of_dump() after the last dump segment has been finished. >> You could call get_new_buffer() instead of the if clause. > Wow, how did you found this? I've fixed it by making sure we flush the DumpWriter before calling the deactivate method. > >> 1064: DumpWriter::DumpWriter() >> >> There doesn't seem to be enough error handling if _buffer cannot be allocated. >> E.g. DumpWriter::write_raw() at line 1091 will enter an endless loop. > As described above, this will not happen if we check for error after constructing the DumpWriter. > >> ### src/java.base/share/native/libzip/zip_util.c >> 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() performance wise. But have you >> measured the performance gain? In other words: is it worth it? :) > This is not done for performance, but to make sure the allocation will not fail midway during writing the dump. Maybe it is not worth it, though. > >> 1655: The result of deflateBound() seems to depend on the header comment, which is not given >> here. Could this be an issue, because ZIP_GZip_Fully() can take a comment? > I've added a 1024 byte additional bytes to avoid the problem. > >> ### test/lib/jdk/test/lib/hprof/parser/Reader.java >> >> 93: is the created GzipRandomAccess instance closed somewhere? > The object is not closed since it is still used by the Snapshot returned. > > Best regard, > Ralf > > > -----Original Message----- > From: Reingruber, Richard > Sent: Tuesday, 14 April 2020 10:30 > To: Schmelter, Ralf ; Ioi Lam ; Langer, Christoph ; Yasumasa Suenaga ; serguei.spitsyn at oracle.com; hotspot-runtime-dev at openjdk.java.net runtime > Cc: serviceability-dev at openjdk.java.net > Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump > > Hi Ralf, > > thanks for providing this enhancement to parallel gzip-compress heap dumps! > > I reckon it's safe to say that the coding is sophisticated. It would be awesome if you could sketch > the idea of how HeapDumper, DumpWriter and CompressionBackend work together to produce the gzipped > dump in a source code comment. Just enough to get started if somebody should ever have to track down > a bug -- an unlikely event, I know ;) > > Please find the details of my review below. > > Thanks, Richard. > // Not Reviewer > > -- > > ### src/hotspot/share/services/diagnosticCommand.cpp > > 510 _gzip_level("-gz-level", "The compression level from 0 (store) to 9 (best) when writing in gzipped format.", > 511 "INT", "FALSE", "1") { > > "FALSE" should be probably false. > > ### src/hotspot/share/services/diagnosticCommand.hpp > Ok. > > ### src/hotspot/share/services/heapDumper.cpp > > 390: Typo: initized > > 415: Typo: GZipComressor > > 477: Could you please add a comment, how the "HPROF BLOCKSIZE" comment is helpful? > > 539: Member variables of WriteWork are missing the '_' prefix. > > 546: Just a comment: WriteWork::in_max is actually a compile time constant. Would be nice if it could be > declared so. One could use templates for this, but then my favourite ide (eclipse cdt) doesn't > show me references and call hierarchies anymore. So I don't think it is worth it. > > 591: Typo: Removes the first element. Returns NULL is empty. > > 663: _writer, _compressor, _lock could be const. > > 762: assert(_active, "Must be active"); > > It appears to me that the assertion would fail, if an error occurred creating the CompressionBackend. > > 767: I think _current->in_used doesn't take the final 9 bytes into account that are written in > DumperSupport::end_of_dump() after the last dump segment has been finished. > You could call get_new_buffer() instead of the if clause. > > 903: Typo: Check if we don not waste more than _max_waste > > 1064: DumpWriter::DumpWriter() > > There doesn't seem to be enough error handling if _buffer cannot be allocated. > E.g. DumpWriter::write_raw() at line 1091 will enter an endless loop. > > 2409: A comment, why Shenandoah is not supported, would be good. > In general I'd say it is good and natural to use the GC work threads. > > ### src/hotspot/share/services/heapDumper.hpp > Ok. > > ### src/java.base/share/native/libzip/zip_util.c > > I'm not familiar with zlib, but here are my .02? :) > > 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() performance wise. But have you > measured the performance gain? In other words: is it worth it? :) > > 1655: The result of deflateBound() seems to depend on the header comment, which is not given > here. Could this be an issue, because ZIP_GZip_Fully() can take a comment? > > 1658: deflateEnd() should not be called if deflateInit2Wrapper() failed. I think this can lead > otherwise to a double free() call. > > ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java > > 66: Maybe additionally check the exit value? > > 73: It's unclear to me, why this fails. Because the dump already exists? Because the level is > invalid? Reading the comment I'd expect success, not failure. > > ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestEpsilon.java > Ok. > > ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestShenandoah.java > Ok. > > ### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestZ.java > Ok. > > ### test/lib/jdk/test/lib/hprof/parser/GzipRandomAccess.java > Ok. > > ### test/lib/jdk/test/lib/hprof/parser/HprofReader.java > Ok. > > ### test/lib/jdk/test/lib/hprof/parser/Reader.java > > 93: is the created GzipRandomAccess instance closed somewhere? From richard.reingruber at sap.com Mon Apr 20 15:02:59 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Mon, 20 Apr 2020 15:02:59 +0000 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: <5a496dbd-abf9-0811-bb93-f35800396479@oss.nttdata.com> References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> <056ba00d-4e1e-f48e-6d7e-10d026b0d2a6@oracle.com> <5a496dbd-abf9-0811-bb93-f35800396479@oss.nttdata.com> Message-ID: Hi Yasumasa, I'm obviously late to this review. Still I wanted to let you know, that there's another file in the source tree that lists the VM operations in the VM (just found out about it myself): src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMOps.java Probably you should remove the VM operations from that file too. It seems to be part of the serviceability agent, which I hardly know. Would be good if somebody who is more familiar with it could let us know... Best regards, Richard. -----Original Message----- From: serviceability-dev On Behalf Of Yasumasa Suenaga Sent: Montag, 20. April 2020 02:33 To: serviceability-dev at openjdk.java.net Cc: yasuenag at gmail.com Subject: Re: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes Hi all, Could you review it? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ I need one more reviewer to push. Thanks, Yasumasa On 2020/04/17 5:13, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > Thank you for the update. > It looks good. > > Thanks, > Serguei > > > On 4/10/20 04:30, Yasumasa Suenaga wrote: >> Hi Serguei, >> >> I use current_jt in this webrev. Could you review again? >> >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ >> >> I tested this change with vmTestbase/nsk/jvmti, they are fine on my Linux x64. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/10 17:21, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> Thank you for the update. >>> >>> Minor: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/src/hotspot/share/prims/jvmtiEnvBase.cpp.udiff.html >>> >>> + err = get_locked_objects_in_frame(JavaThread::current(), java_thread, jvf, owned_monitors_list, depth-1); . . . >>> >>> + JvmtiMonitorClosure jmc(java_thread, JavaThread::current(), owned_monitors_list, this); >>> >>> You can use current_jt instead of JavaThread::current() above. >>> >>> There is also some test coverage in the vmTestbase/nsk/jvmti/scenarios tests. >>> This one as well: >>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest >>> Probably it is easier to run all vmTestbase/nsk/jvmti tests. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/10/20 01:05, Yasumasa Suenaga wrote: >>>> Hi Serguei, >>>> >>>> Thanks for your comment! >>>> I uploaded new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/ >>>> >>>> I ran following tests, and all of them were passed on my Linux x64. >>>> >>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>> ?- vmTestbase/nsk/jdi >>>> ?- vmTestbase/nsk/jdwp >>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>> ?- serviceability/jdwp >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/04/10 14:50, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa, >>>>> >>>>> It looks pretty good in general. >>>>> A couple of comments though. >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html >>>>> >>>>> 650 JvmtiEnvBase::get_current_contended_monitor(JavaThread *java_thread, jobject *monitor_ptr) { >>>>> 651 assert(!Thread::current()->is_VM_thread() && >>>>> 652 (Thread::current() == java_thread || >>>>> 653 Thread::current() == java_thread->active_handshaker()), >>>>> 654 "call by myself or at direct handshake"); >>>>> >>>>> ? ... >>>>> >>>>> 685 JvmtiEnvBase::get_owned_monitors(JavaThread* java_thread, >>>>> ? 686 GrowableArray *owned_monitors_list) { >>>>> ? 687?? jvmtiError err = JVMTI_ERROR_NONE; >>>>> 688 assert(!Thread::current()->is_VM_thread() && >>>>> 689 (Thread::current() == java_thread || >>>>> 690 Thread::current() == java_thread->active_handshaker()), >>>>> 691 "call by myself or at direct handshake"); >>>>> >>>>> I'd suggest to add this at the beginning: >>>>> ?? JavaThread *current_jt = JavaThread::current(); >>>>> >>>>> >>>>> 676 JavaThread *current_jt = reinterpret_cast(JavaThread::current()); >>>>> >>>>> There is not need in reinterpret_cast. Also, you can use the current_jt defined above. >>>>> >>>>> Also, please, removed these two definitions as they became unused with your fix: >>>>> ??? src/hotspot/share/runtime/vmOperations.hpp: template(GGetCurrentContendedMonitoretOwnedMonitorInfo) \ >>>>> ??? src/hotspot/share/runtime/vmOperations.hpp: template()??????????? \ >>>>> >>>>> The impacted JVMTI monitor functions are used in the JDWP agent to support the JDI ThreadReference implementation. >>>>> To be safe the JDI & JDWP tests have to be run as well. It is well covered by the tier-5. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 4/9/20 21:46, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this change: >>>>>> >>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >>>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/ >>>>>> >>>>>> We've discussed to use Thread-Local Handshake in some JVMTI functions [1]. >>>>>> This change is for monitor functions. It affects GetOwnedMonitorInfo(), GetOwnedMonitorStackDepthInfo(), GetCurrentContendedMonitor(). >>>>>> >>>>>> It passed tests on submit repo (mach5-one-ysuenaga-JDK-8242425-20200410-0228-10075639), and also I confirmed to pass following tests: >>>>>> >>>>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html >>>>> >>> > From chris.plummer at oracle.com Mon Apr 20 17:46:12 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 20 Apr 2020 10:46:12 -0700 Subject: RFR(XS) 8242789: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with 'JShellToolProvider' missing from stdout/stderr In-Reply-To: <0f377e45-63bc-8352-c9b6-984578a706d2@oracle.com> References: <0f377e45-63bc-8352-c9b6-984578a706d2@oracle.com> Message-ID: <36d509ff-b48e-2961-c63f-44f5fdb796b7@oracle.com> Ping. This is a very simple change. thanks, Chris On 4/17/20 10:30 AM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8242789 > http://cr.openjdk.java.net/~cjplummer/8242789/webrev.00 > > JShellHeapDumpTest.java has two variants, one that does a short 2 > second sleep after launching the jshell process (the main > JShellHeapDumpTest.java test does this) and the other that does no > sleep (HeapDumpTestWithActiveProcess.java does this by invoking > JShellHeapDumpTest.java with the "nosleep" argument). > > The reason for the 2 second sleep is to get the jshell process into a > steady state so JDK-8231634 [1] doesn't turn up when using SA on the > jshell process. I added the sleep instead of problem listing > JShellHeapDumpTest.java since it is a useful? test even with the sleep > in place. HeapDumpTestWithActiveProcess.java was added so we still had > a test to reproduce JDK-8231634 [1], and was problem listed > immediately. However, another side affect of not sleeping is sometimes > SA requests the thread dump of the jshell process before jshell enters > its main thread. Thus the test can't find the "JShellToolProvider" > symbol in the thread dump. The fix is to simply not require the symbol > to be present when in "nosleep" mode. > > thanks, > > Chris > > [1] https://bugs.openjdk.java.net/browse/JDK-8231634 > From serguei.spitsyn at oracle.com Mon Apr 20 18:58:49 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 Apr 2020 11:58:49 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <358b4e34-66e7-6ae3-82f3-5c5d9bf77333@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> <9b74fc5f-0cb0-e0f5-6a36-969db3deff0a@oracle.com> <358b4e34-66e7-6ae3-82f3-5c5d9bf77333@oracle.com> Message-ID: <71f6e86c-970f-ef34-570e-c856fc202f29@oracle.com> Hi Mandy, Thank you for the update! I like it as it is a good compromise. I do not see any wording issues. Thanks, Serguei On 4/18/20 15:28, Mandy Chung wrote: > Hi Chris, Serguei, > > On 4/18/20 12:18 AM, Chris Plummer wrote: >> >> Yes. I'd like to see all this as part of the Class/Classloading spec >> in some sort of section that gives an overview of all these topics, >> but mostly clarifies what an initiating loader is, and the (non) >> relationship to hidden classes. > > We should refer initiating loader and class loading from JVMS 5.3. ? > JVM TI needs the clarification w.r.t.? GetClassLoaderClasses that does > not include hidden classes because the initiating class loader cannot > find it. > > GetLoadedClasses is about class creation.?? While it seems tempted to > put the descriptions in some sort of overview section, I found the > clarification is specific for each function and hence inlining them in > each function helps the readers directly see the difference. > > I made a few changes that should ease your concern of duplication: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes.01/ > > - The class creation description added in GetLoadedClasses.? Not in > JDWP, JDI and Instrumentation. > - The description in GetClassLoaderClasses, > Instrumentation::getInitiatedClasses, > ClassLoaderReference::visibleClasses is revised to take out the > details.?? Add links from JDWP and JDI to GetClassLoaderClasses. > - The details about hidden classes can be found from `Class::isHidden` > and? ??? `Lookup::defineHiddenClass`. > > Mandy From serguei.spitsyn at oracle.com Mon Apr 20 19:03:21 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 Apr 2020 12:03:21 -0700 Subject: RFR(XS) 8242789: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with 'JShellToolProvider' missing from stdout/stderr In-Reply-To: <36d509ff-b48e-2961-c63f-44f5fdb796b7@oracle.com> References: <0f377e45-63bc-8352-c9b6-984578a706d2@oracle.com> <36d509ff-b48e-2961-c63f-44f5fdb796b7@oracle.com> Message-ID: <9108e173-6c21-4f5c-11ae-9ecd3d342af0@oracle.com> Hi Chris, LGTM Thanks, Serguei On 4/20/20 10:46, Chris Plummer wrote: > Ping. This is a very simple change. > > thanks, > > Chris > > On 4/17/20 10:30 AM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8242789 >> http://cr.openjdk.java.net/~cjplummer/8242789/webrev.00 >> >> JShellHeapDumpTest.java has two variants, one that does a short 2 >> second sleep after launching the jshell process (the main >> JShellHeapDumpTest.java test does this) and the other that does no >> sleep (HeapDumpTestWithActiveProcess.java does this by invoking >> JShellHeapDumpTest.java with the "nosleep" argument). >> >> The reason for the 2 second sleep is to get the jshell process into a >> steady state so JDK-8231634 [1] doesn't turn up when using SA on the >> jshell process. I added the sleep instead of problem listing >> JShellHeapDumpTest.java since it is a useful test even with the sleep >> in place. HeapDumpTestWithActiveProcess.java was added so we still >> had a test to reproduce JDK-8231634 [1], and was problem listed >> immediately. However, another side affect of not sleeping is >> sometimes SA requests the thread dump of the jshell process before >> jshell enters its main thread. Thus the test can't find the >> "JShellToolProvider" symbol in the thread dump. The fix is to simply >> not require the symbol to be present when in "nosleep" mode. >> >> thanks, >> >> Chris >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8231634 >> > > From joe.darcy at oracle.com Mon Apr 20 19:19:12 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 20 Apr 2020 12:19:12 -0700 Subject: RFR: JDK-8242943 Fix all remaining unchecked warnings in jdk.hotspot.agent In-Reply-To: References: Message-ID: Hello, On 4/16/2020 5:47 AM, Magnus Ihse Bursie wrote: [snip] > The tricky one here is the helper TableModelComparator. This one took > me a while to wrap my head around. It implements Comparator, but the > compare() method takes "rows" from the model, which are just expressed > as Objects, and left to subclasses to define differently. For one of > the subclasses it uses the type T that the TableModel is created > around, but in other it uses an independent domain model. :-/ Anyway. > The compare() method then extracts data for the individual columns of > each row using the method getValueForColumn(), and compare them > pairwise. This data from the rows are supposed to implement Comparable. > > In the end, I think I got it pretty OK, but I'm still an apprentice > when it comes to generics black magic. The subclasses of > TableModelComparator want to return different objects from > getValueForColumn() for different columns in the row, like Long or > String. They are all Comparable, but String is Comparable and > Long is Comparable. So I needed to specify the abstract method > as returning Comparable, since Comparable is not > Comparable. > > But then, for reasons that I do not fully fathom, I could not specify > > Comparable o1 = getValueForColumn(row1, columns[i]); > Comparable o2 = getValueForColumn(row2, columns[i]); > int result = o1.compareTo(o2); > > because the compiler did not accept the call to compareTo(). > > I did try to sacrifice a black rooster at midnight and walking > backwards in a circle three time, to no avail. Maybe the problem was > that it was not full moon or that I have no cat. In the end, I casted > o1 and o2 to Comparable and suppressed the warning for that cast. > > If anyone knows what rituals I need to perform to make this work, or > -- even better -- how to fix the code properly, please let me know! A brief discussion of wildcards, ?. The meaning of a wildcard is some particular unknown type, meeting the various? constraints from "? extends" or "? super".? If there is no explicit constraint listed, it is equivalent to "? extends Object". So the meaning of the code above is something Comparable o1 = getValueForColumn(row1, columns[i]); Comparable o2 = getValueForColumn(row2, columns[i]); where S and T are two fresh, unrelated type variables. Concretely, this means S and T could be, say, String and Integer so that is why a call to o1.compareTo(o2) would not be accepted by the compiler since Strings and Integer aren't comparable to each other. While two instances of "Comparable" are syntactically the same, they don't represent the same type inside the compiler. In some cases, you can get around this issue by using a separate method to capture the type variable and then use it more than once. A technique we've used in the JDK is to have a pubic method with a wildcards calling a private method using a type variable. I've looked around for a few minutes and didn't find a concrete example in the JDK, but they're in there. I haven't looked over the specific code here in much detail; the type Comparable might to be the best you can do, but it isn't very expressive since Object's aren't necessarily comparable. HTH, -Joe From chris.plummer at oracle.com Mon Apr 20 20:06:07 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 20 Apr 2020 13:06:07 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <358b4e34-66e7-6ae3-82f3-5c5d9bf77333@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> <9b74fc5f-0cb0-e0f5-6a36-969db3deff0a@oracle.com> <358b4e34-66e7-6ae3-82f3-5c5d9bf77333@oracle.com> Message-ID: <461f9faa-fc7b-0b2a-22f1-e8dd9eb5fc8e@oracle.com> On 4/18/20 3:28 PM, Mandy Chung wrote: > Hi Chris, Serguei, > > On 4/18/20 12:18 AM, Chris Plummer wrote: >> >> Yes. I'd like to see all this as part of the Class/Classloading spec >> in some sort of section that gives an overview of all these topics, >> but mostly clarifies what an initiating loader is, and the (non) >> relationship to hidden classes. > > We should refer initiating loader and class loading from JVMS 5.3. ? > JVM TI needs the clarification w.r.t.? GetClassLoaderClasses that does > not include hidden classes because the initiating class loader cannot > find it. > > GetLoadedClasses is about class creation.?? While it seems tempted to > put the descriptions in some sort of overview section, I found the > clarification is specific for each function and hence inlining them in > each function helps the readers directly see the difference. > > I made a few changes that should ease your concern of duplication: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes.01/ > > - The class creation description added in GetLoadedClasses.? Not in > JDWP, JDI and Instrumentation. > - The description in GetClassLoaderClasses, > Instrumentation::getInitiatedClasses, > ClassLoaderReference::visibleClasses is revised to take out the > details.?? Add links from JDWP and JDI to GetClassLoaderClasses. > - The details about hidden classes can be found from `Class::isHidden` > and? ??? `Lookup::defineHiddenClass`. > > Mandy Hi Mandy, This looks much better. Thank you for the consolidating and the cross references. I think that's a big improvement. One minor thing I noticed is a few "JNI-style signature" references. In LocalVariable.java you renamed "JNI signature" to "JNI-style signature", but in JDI Mirror.java you renamed "JNI-style signature" to "type signature". And then in JDI TypeComponent.java you left the "JNI-style signature" reference unchanged. Why the inconsistency? In VirtualMachine.java: ?145????? * @see Class or interface creation specified in ?146????? * JVM TI GetLoadedClasses How about: ?145????? * @a description of how Class and interface creation can be triggered is specified in ?146????? * JVM TI GetLoadedClasses I read the following incorrectly a few times before I finally understood the meaning: ? 44???? /** ? 45????? * Returns the {@linkplain com.sun.jdi.Type#name() name of the class} ? 46????? * that has been unloaded. The returned string may not be a ? 47????? * binary name. ? 48????? * ? 49????? * @see Class#getName() ? 50????? */ ? 51???? public String className(); ? 52 ? 53???? /** ? 54????? * Returns the {@linkplain com.sun.jdi.Type#signature() type signature of the class} ? 55????? * that has been unloaded.? The returned string may not be a type descriptor ? 56????? * specified in JVMS {@jvms 4.3.2}. ? 57????? * ? 58????? * @see java.lang.invoke.TypeDescriptor#descriptorString() ? 59????? */ ? 60???? public String classSignature(); "may not be" through me off. I read it as "is not allowed not be". Your intent was "might not be", which might be a better choice of words. thanks, Chris From chris.plummer at oracle.com Mon Apr 20 20:56:47 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 20 Apr 2020 13:56:47 -0700 Subject: RFR(XS) 8243206: Cleanup error checking and handling in serviceability/sa/JhsdbThreadInfoTest.java Message-ID: <4f53e2b8-f976-9bd3-1392-a0f4b9fb45a6@oracle.com> Hello, Please review the following simple fixes to JhsdbThreadInfoTest.java. Details are in the CR description. https://bugs.openjdk.java.net/browse/JDK-8243206 http://cr.openjdk.java.net/~cjplummer/8243206/webrev.00/ thanks, Chris From mandy.chung at oracle.com Mon Apr 20 20:57:36 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 20 Apr 2020 13:57:36 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: <461f9faa-fc7b-0b2a-22f1-e8dd9eb5fc8e@oracle.com> References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> <9b74fc5f-0cb0-e0f5-6a36-969db3deff0a@oracle.com> <358b4e34-66e7-6ae3-82f3-5c5d9bf77333@oracle.com> <461f9faa-fc7b-0b2a-22f1-e8dd9eb5fc8e@oracle.com> Message-ID: On 4/20/20 1:06 PM, Chris Plummer wrote: > On 4/18/20 3:28 PM, Mandy Chung wrote: >> Hi Chris, Serguei, >> >> On 4/18/20 12:18 AM, Chris Plummer wrote: >>> >>> Yes. I'd like to see all this as part of the Class/Classloading spec >>> in some sort of section that gives an overview of all these topics, >>> but mostly clarifies what an initiating loader is, and the (non) >>> relationship to hidden classes. >> >> We should refer initiating loader and class loading from JVMS 5.3. ? >> JVM TI needs the clarification w.r.t. GetClassLoaderClasses that does >> not include hidden classes because the initiating class loader cannot >> find it. >> >> GetLoadedClasses is about class creation.?? While it seems tempted to >> put the descriptions in some sort of overview section, I found the >> clarification is specific for each function and hence inlining them >> in each function helps the readers directly see the difference. >> >> I made a few changes that should ease your concern of duplication: >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes.01/ >> >> >> - The class creation description added in GetLoadedClasses.? Not in >> JDWP, JDI and Instrumentation. >> - The description in GetClassLoaderClasses, >> Instrumentation::getInitiatedClasses, >> ClassLoaderReference::visibleClasses is revised to take out the >> details.?? Add links from JDWP and JDI to GetClassLoaderClasses. >> - The details about hidden classes can be found from >> `Class::isHidden` and? ??? `Lookup::defineHiddenClass`. >> >> Mandy > Hi Mandy, > > This looks much better. Thank you for the consolidating and the cross > references. I think that's a big improvement. > > One minor thing I noticed is a few "JNI-style signature" references. > In LocalVariable.java you renamed "JNI signature" to "JNI-style > signature", but in JDI Mirror.java you renamed "JNI-style signature" > to "type signature". You meant Type::signature.?? Type::signature may return the type signature of a hidden class whereas LocalVariable::signature and TypeComponent::signature return the field/method descriptor where no hidden class will appear in a resolved field/variable/method. > And then in JDI TypeComponent.java you left the "JNI-style signature" > reference unchanged. Why the inconsistency? > I made LocalVariable::signature consistent with TypeComponent::signature whereas Type::signature returns the string of the form described in Class::descriptorString. I tried to keep existing reference to use "JNI-style signature". Since I touched on these files, I can change them to "type signature" which applies to these cases but I will leave the link to the JNI spec as it is. > In VirtualMachine.java: > > ?145????? * @see Class or interface creation specified in > ?146????? * href="{@docRoot}/../specs/jvmti/jvmti.html#GetLoadedClasses">JVM TI > GetLoadedClasses > > How about: > > ?145????? * @a description of how Class and interface creation can be > triggered is specified in > ?146????? * href="{@docRoot}/../specs/jvmti/jvmti.html#GetLoadedClasses">JVM TI > GetLoadedClasses > ???? * @see ???? * JVM TI GetLoadedClasses regarding how class and interface creation can be triggered > I read the following incorrectly a few times before I finally > understood the meaning: > > 44???? /** > ? 45????? * Returns the {@linkplain com.sun.jdi.Type#name() name of > the class} > ? 46????? * that has been unloaded. The returned string may not be a > ? 47????? * href="${docRoot}/java.base/java/lang/ClassLoader.html#binary-name">binary > name. > ? 48????? * > ? 49????? * @see Class#getName() > ? 50????? */ > ? 51???? public String className(); > ? 52 > ? 53???? /** > ? 54????? * Returns the {@linkplain com.sun.jdi.Type#signature() type > signature of the class} > ? 55????? * that has been unloaded.? The returned string may not be a > type descriptor > ? 56????? * specified in JVMS {@jvms 4.3.2}. > ? 57????? * > ? 58????? * @see java.lang.invoke.TypeDescriptor#descriptorString() > ? 59????? */ > ? 60???? public String classSignature(); > > "may not be" through me off. I read it as "is not allowed not be". > Your intent was "might not be", which might be a better choice of words. > I make it clearer as: ???? * Returns the {@linkplain com.sun.jdi.Type#signature() type signature of the class} ???? * that has been unloaded.? The result is of the same ???? * form as the string returned by {@link Class#descriptorString()}. ???? * If this class can be described nominally, the returned string is a ???? * type descriptor conforming to JVMS {@jvms 4.3.2}; otherwise, the returned string ???? * is not a type descriptor. Similar clarification is also made in Type::signature: ???? * Returns the type signature for this type.? The result is of the same ???? * form as the string returned by {@link Class#descriptorString()}. ???? * The returned string is a type descriptor conforming to JVMS {@jvms 4.3.2} ???? * if this type can be described nominally.? Otherwise, the returned string ???? * is not a type descriptor. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Apr 20 21:02:04 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 20 Apr 2020 14:02:04 -0700 Subject: Review Request: 8238358: Implementation of JEP 371: Hidden Classes In-Reply-To: References: <0d824617-3eaf-727c-6eb8-be2414111510@oracle.com> <1a5eb022-dd7e-b0bb-750f-c43be195eb42@oracle.com> <4A360464-1873-43A8-B423-C93D1BEF9895@oracle.com> <51adeaaf-9c85-240c-ed0d-f460c117ba46@oracle.com> <6890c88c-809b-fbea-aa10-675661ef2c68@oracle.com> <440544f0-8a74-7ff1-8b78-0c20307bb89a@oracle.com> <9b74fc5f-0cb0-e0f5-6a36-969db3deff0a@oracle.com> <358b4e34-66e7-6ae3-82f3-5c5d9bf77333@oracle.com> <461f9faa-fc7b-0b2a-22f1-e8dd9eb5fc8e@oracle.com> Message-ID: On 4/20/20 1:57 PM, Mandy Chung wrote: > > > On 4/20/20 1:06 PM, Chris Plummer wrote: >> On 4/18/20 3:28 PM, Mandy Chung wrote: >>> Hi Chris, Serguei, >>> >>> On 4/18/20 12:18 AM, Chris Plummer wrote: >>>> >>>> Yes. I'd like to see all this as part of the Class/Classloading >>>> spec in some sort of section that gives an overview of all these >>>> topics, but mostly clarifies what an initiating loader is, and the >>>> (non) relationship to hidden classes. >>> >>> We should refer initiating loader and class loading from JVMS 5.3. ? >>> JVM TI needs the clarification w.r.t. GetClassLoaderClasses that >>> does not include hidden classes because the initiating class loader >>> cannot find it. >>> >>> GetLoadedClasses is about class creation.?? While it seems tempted >>> to put the descriptions in some sort of overview section, I found >>> the clarification is specific for each function and hence inlining >>> them in each function helps the readers directly see the difference. >>> >>> I made a few changes that should ease your concern of duplication: >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes.01/ >>> >>> >>> - The class creation description added in GetLoadedClasses. Not in >>> JDWP, JDI and Instrumentation. >>> - The description in GetClassLoaderClasses, >>> Instrumentation::getInitiatedClasses, >>> ClassLoaderReference::visibleClasses is revised to take out the >>> details.?? Add links from JDWP and JDI to GetClassLoaderClasses. >>> - The details about hidden classes can be found from >>> `Class::isHidden` and? ??? `Lookup::defineHiddenClass`. >>> >>> Mandy >> Hi Mandy, >> >> This looks much better. Thank you for the consolidating and the cross >> references. I think that's a big improvement. >> >> One minor thing I noticed is a few "JNI-style signature" references. >> In LocalVariable.java you renamed "JNI signature" to "JNI-style >> signature", but in JDI Mirror.java you renamed "JNI-style signature" >> to "type signature". > > You meant Type::signature.?? Type::signature may return the type > signature of a hidden class whereas LocalVariable::signature and > TypeComponent::signature return the field/method descriptor where no > hidden class will appear in a resolved field/variable/method. ok > >> And then in JDI TypeComponent.java you left the "JNI-style signature" >> reference unchanged. Why the inconsistency? >> > I made LocalVariable::signature consistent with > TypeComponent::signature whereas Type::signature returns the string of > the form described in Class::descriptorString. > > I tried to keep existing reference to use "JNI-style signature". Since > I touched on these files, I can change them to "type signature" which > applies to these cases but I will leave the link to the JNI spec as it is. ok > >> In VirtualMachine.java: >> >> ?145????? * @see Class or interface creation specified in >> ?146????? * > href="{@docRoot}/../specs/jvmti/jvmti.html#GetLoadedClasses">JVM TI >> GetLoadedClasses >> >> How about: >> >> ?145????? * @a description of how Class and interface creation can be >> triggered is specified in >> ?146????? * > href="{@docRoot}/../specs/jvmti/jvmti.html#GetLoadedClasses">JVM TI >> GetLoadedClasses >> > > ???? * @see href="{@docRoot}/../specs/jvmti/jvmti.html#GetLoadedClasses"> > ???? * JVM TI GetLoadedClasses regarding how class and interface > creation can be triggered That's better. > >> I read the following incorrectly a few times before I finally >> understood the meaning: >> >> 44???? /** >> ? 45????? * Returns the {@linkplain com.sun.jdi.Type#name() name of >> the class} >> ? 46????? * that has been unloaded. The returned string may not be a >> ? 47????? * > href="${docRoot}/java.base/java/lang/ClassLoader.html#binary-name">binary >> name. >> ? 48????? * >> ? 49????? * @see Class#getName() >> ? 50????? */ >> ? 51???? public String className(); >> ? 52 >> ? 53???? /** >> ? 54????? * Returns the {@linkplain com.sun.jdi.Type#signature() type >> signature of the class} >> ? 55????? * that has been unloaded.? The returned string may not be a >> type descriptor >> ? 56????? * specified in JVMS {@jvms 4.3.2}. >> ? 57????? * >> ? 58????? * @see java.lang.invoke.TypeDescriptor#descriptorString() >> ? 59????? */ >> ? 60???? public String classSignature(); >> >> "may not be" through me off. I read it as "is not allowed not be". >> Your intent was "might not be", which might be a better choice of words. >> > > I make it clearer as: > > ???? * Returns the {@linkplain com.sun.jdi.Type#signature() type > signature of the class} > ???? * that has been unloaded.? The result is of the same > ???? * form as the string returned by {@link Class#descriptorString()}. > ???? * If this class can be described nominally, the returned string is a > ???? * type descriptor conforming to JVMS {@jvms 4.3.2}; otherwise, > the returned string > ???? * is not a type descriptor. > > Similar clarification is also made in Type::signature: > > ???? * Returns the type signature for this type.? The result is of the > same > ???? * form as the string returned by {@link Class#descriptorString()}. > ???? * The returned string is a type descriptor conforming to JVMS > {@jvms 4.3.2} > ???? * if this type can be described nominally.? Otherwise, the > returned string > ???? * is not a type descriptor. Great! thanks, Chris > > Mandy From alexey.menkov at oracle.com Mon Apr 20 23:37:54 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 20 Apr 2020 16:37:54 -0700 Subject: RFR(XS) 8243206: Cleanup error checking and handling in serviceability/sa/JhsdbThreadInfoTest.java In-Reply-To: <4f53e2b8-f976-9bd3-1392-a0f4b9fb45a6@oracle.com> References: <4f53e2b8-f976-9bd3-1392-a0f4b9fb45a6@oracle.com> Message-ID: <863abb57-a164-1a08-72e7-c2122778a4fe@oracle.com> Hi Chris, LGTM --alex On 04/20/2020 13:56, Chris Plummer wrote: > Hello, > > Please review the following simple fixes to JhsdbThreadInfoTest.java. > Details are in the CR description. > > https://bugs.openjdk.java.net/browse/JDK-8243206 > http://cr.openjdk.java.net/~cjplummer/8243206/webrev.00/ > > thanks, > > Chris From serguei.spitsyn at oracle.com Tue Apr 21 00:14:38 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 Apr 2020 17:14:38 -0700 Subject: RFR(XS) 8243206: Cleanup error checking and handling in serviceability/sa/JhsdbThreadInfoTest.java In-Reply-To: <863abb57-a164-1a08-72e7-c2122778a4fe@oracle.com> References: <4f53e2b8-f976-9bd3-1392-a0f4b9fb45a6@oracle.com> <863abb57-a164-1a08-72e7-c2122778a4fe@oracle.com> Message-ID: <973744fe-54a4-8699-7bad-9b3a90ebb90b@oracle.com> LGTM++ Thanks, Serguei On 4/20/20 16:37, Alex Menkov wrote: > Hi Chris, > > LGTM > > --alex > > On 04/20/2020 13:56, Chris Plummer wrote: >> Hello, >> >> Please review the following simple fixes to JhsdbThreadInfoTest.java. >> Details are in the CR description. >> >> https://bugs.openjdk.java.net/browse/JDK-8243206 >> http://cr.openjdk.java.net/~cjplummer/8243206/webrev.00/ >> >> thanks, >> >> Chris From serguei.spitsyn at oracle.com Tue Apr 21 00:18:39 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 Apr 2020 17:18:39 -0700 Subject: RFR: JDK-8242943 Fix all remaining unchecked warnings in jdk.hotspot.agent In-Reply-To: References: Message-ID: <7eaea2a3-e73d-949c-35c0-902ee9ac75ac@oracle.com> Hi Magnus, This looks pretty good to me. I hope, Joe gave some insight for Comparable's. Thanks, Serguei On 4/16/20 05:47, Magnus Ihse Bursie wrote: > This is the final part of removing all warnings from the build of > jdk.hotspot.agent. This patch includes a number of non-trivial fixes > for the few remaining unchecked warnings. > > The good news is that with this fix (and after the recent removal of > Nashorn and rmic), the JDK build is finally complete free from > warnings for the first time ever! EPIC!!!!!1!!! :-) > > The bad news is that this patch is probably the most complex of all > I've posted so far. :-/ > > I'll break down the changes in four groups: > > * ConstMethod superclass issue > > ConstMethod current extends VMObject. However, it is treated as a > Metadata (Metadata is a subtype of VMObject). For instance, this code > appears in Metadata.java: > ? metadataConstructor.addMapping("ConstMethod", ConstMethod.class); > > I believe it is just an oversight that ConstMethod does not also > extend Metadata like the rest of the classes added to the > metadataConstructor mapping, one which has not been caught without the > extra type safety given by generics. > > * ProfileData casting > > In several places, a ProfileData item is extracted from a collection, > its type checked with instanceof, and then acted on accordingly. > (Yeah, nice and clean OOP abstraction at work! :-)) > > This works well most of the time, but when casting to ReceiverTypeData > or CallTypeDataInterface, the type include generic parametrisation, so > it needs to be cast to e.g. ReceiverTypeData. > Unfortunately, this cannot be verified using instanceof, due to > generic type erasure, and thus the compiler considers this an > unchecked cast. (At least, this is my understanding of what is > happening.) As far as I can tell, this is legitimate code, and the > only way to really handle this (barring a more extensive rewrite) is > to disable the warning for these cases. > > * Generification of the InstanceConstructor hierarchy > > I have properly generified the InstanceConstructor hierarchy, with the > VirtualConstructor, StaticBaseConstructor and VirtualBaseConstructor > subclasses. (And also the related helper class VMObjectFactory.) > > Most of it turned out OK (and with improved type safety), but there > was one piece of code that is a bit unfortunate. In > VirtualBaseConstructor, we have the following: > ??????????? @SuppressWarnings("unchecked") > ??????????? Class lookedUpClass = (Class T>)Class.forName(packageName + "." + superType.getName()); > ??????????? c = lookedUpClass; > > That is, we send in a name for a class and assumes that it will > resolve to a subtype of T, but there is no way to enforce this with > type safety. I have verified all current callers to the constructor so > that they all abide to this rule (of course, otherwise the code would > not have worked, but I checked it anyway). The alternative to > suppressing the warning is to redesign the entire API, so we do not > send in a class name, but instead a Class, and use that > to extract the name instead. At this point, I don't find it worth it. > This is, after all, no worse than it was before. > > * SortableTableModel and TableModelComparator > > This one was quite messy. The tables are being used in quite different > ways in different places, which made it hard to generify in a good > way. A lot of it revolves around keeping the data as Objects and > casting it to a known type. (Some of this behavior comes from the fact > that they extend old Swing classes which does this.) I've tried to > tighten it up as much as possible by introducing increased type safety > by generification, but in the end, it was not fully possible to do > without a major surgery of the entire class structure. As above, most > of it turned out OK, but not all. > > The tricky one here is the helper TableModelComparator. This one took > me a while to wrap my head around. It implements Comparator, but the > compare() method takes "rows" from the model, which are just expressed > as Objects, and left to subclasses to define differently. For one of > the subclasses it uses the type T that the TableModel is created > around, but in other it uses an independent domain model. :-/ Anyway. > The compare() method then extracts data for the individual columns of > each row using the method getValueForColumn(), and compare them > pairwise. This data from the rows are supposed to implement Comparable. > > In the end, I think I got it pretty OK, but I'm still an apprentice > when it comes to generics black magic. The subclasses of > TableModelComparator want to return different objects from > getValueForColumn() for different columns in the row, like Long or > String. They are all Comparable, but String is Comparable and > Long is Comparable. So I needed to specify the abstract method > as returning Comparable, since Comparable is not > Comparable. > > But then, for reasons that I do not fully fathom, I could not specify > > Comparable o1 = getValueForColumn(row1, columns[i]); > Comparable o2 = getValueForColumn(row2, columns[i]); > int result = o1.compareTo(o2); > > because the compiler did not accept the call to compareTo(). > > I did try to sacrifice a black rooster at midnight and walking > backwards in a circle three time, to no avail. Maybe the problem was > that it was not full moon or that I have no cat. In the end, I casted > o1 and o2 to Comparable and suppressed the warning for that cast. > > If anyone knows what rituals I need to perform to make this work, or > -- even better -- how to fix the code properly, please let me know! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242943 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8242943-SA-final-unchecked-warnings/webrev.01 > > /Magnus From suenaga at oss.nttdata.com Tue Apr 21 00:24:04 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 21 Apr 2020 09:24:04 +0900 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> <056ba00d-4e1e-f48e-6d7e-10d026b0d2a6@oracle.com> <5a496dbd-abf9-0811-bb93-f35800396479@oss.nttdata.com> Message-ID: <9856771f-85a3-d490-1d19-5c0afd5f0438@oss.nttdata.com> Hi Rechard, Thank you for telling it to me. I grep'ed jdk.hotspot.agent with VMOps (it is just enum), it does not seem to be used. In addition, VMOps has not already synced to HotSpot. For example, VM_HandshakeOneThread does not appear in VMOps. (I wonder how do we use VMOps in SA) Thus I think we can (should) remove VMOps from jdk.hotspot.agent . If other serviceability folks agree with it, I will file it to JBS. Thanks, Yasumasa On 2020/04/21 0:02, Reingruber, Richard wrote: > Hi Yasumasa, > > I'm obviously late to this review. Still I wanted to let you know, that there's another file in the > source tree that lists the VM operations in the VM (just found out about it myself): > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMOps.java > > Probably you should remove the VM operations from that file too. > > It seems to be part of the serviceability agent, which I hardly know. Would be good if somebody > who is more familiar with it could let us know... > > Best regards, > Richard. > > -----Original Message----- > From: serviceability-dev On Behalf Of Yasumasa Suenaga > Sent: Montag, 20. April 2020 02:33 > To: serviceability-dev at openjdk.java.net > Cc: yasuenag at gmail.com > Subject: Re: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes > > Hi all, > > Could you review it? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ > > I need one more reviewer to push. > > > Thanks, > > Yasumasa > > > On 2020/04/17 5:13, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> Thank you for the update. >> It looks good. >> >> Thanks, >> Serguei >> >> >> On 4/10/20 04:30, Yasumasa Suenaga wrote: >>> Hi Serguei, >>> >>> I use current_jt in this webrev. Could you review again? >>> >>> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ >>> >>> I tested this change with vmTestbase/nsk/jvmti, they are fine on my Linux x64. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/04/10 17:21, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> Thank you for the update. >>>> >>>> Minor: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/src/hotspot/share/prims/jvmtiEnvBase.cpp.udiff.html >>>> >>>> + err = get_locked_objects_in_frame(JavaThread::current(), java_thread, jvf, owned_monitors_list, depth-1); . . . >>>> >>>> + JvmtiMonitorClosure jmc(java_thread, JavaThread::current(), owned_monitors_list, this); >>>> >>>> You can use current_jt instead of JavaThread::current() above. >>>> >>>> There is also some test coverage in the vmTestbase/nsk/jvmti/scenarios tests. >>>> This one as well: >>>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest >>>> Probably it is easier to run all vmTestbase/nsk/jvmti tests. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/10/20 01:05, Yasumasa Suenaga wrote: >>>>> Hi Serguei, >>>>> >>>>> Thanks for your comment! >>>>> I uploaded new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/ >>>>> >>>>> I ran following tests, and all of them were passed on my Linux x64. >>>>> >>>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>> ?- vmTestbase/nsk/jdi >>>>> ?- vmTestbase/nsk/jdwp >>>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>> ?- serviceability/jdwp >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2020/04/10 14:50, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> It looks pretty good in general. >>>>>> A couple of comments though. >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html >>>>>> >>>>>> 650 JvmtiEnvBase::get_current_contended_monitor(JavaThread *java_thread, jobject *monitor_ptr) { >>>>>> 651 assert(!Thread::current()->is_VM_thread() && >>>>>> 652 (Thread::current() == java_thread || >>>>>> 653 Thread::current() == java_thread->active_handshaker()), >>>>>> 654 "call by myself or at direct handshake"); >>>>>> >>>>>> ? ... >>>>>> >>>>>> 685 JvmtiEnvBase::get_owned_monitors(JavaThread* java_thread, >>>>>> ? 686 GrowableArray *owned_monitors_list) { >>>>>> ? 687?? jvmtiError err = JVMTI_ERROR_NONE; >>>>>> 688 assert(!Thread::current()->is_VM_thread() && >>>>>> 689 (Thread::current() == java_thread || >>>>>> 690 Thread::current() == java_thread->active_handshaker()), >>>>>> 691 "call by myself or at direct handshake"); >>>>>> >>>>>> I'd suggest to add this at the beginning: >>>>>> ?? JavaThread *current_jt = JavaThread::current(); >>>>>> >>>>>> >>>>>> 676 JavaThread *current_jt = reinterpret_cast(JavaThread::current()); >>>>>> >>>>>> There is not need in reinterpret_cast. Also, you can use the current_jt defined above. >>>>>> >>>>>> Also, please, removed these two definitions as they became unused with your fix: >>>>>> ??? src/hotspot/share/runtime/vmOperations.hpp: template(GGetCurrentContendedMonitoretOwnedMonitorInfo) \ >>>>>> ??? src/hotspot/share/runtime/vmOperations.hpp: template()??????????? \ >>>>>> >>>>>> The impacted JVMTI monitor functions are used in the JDWP agent to support the JDI ThreadReference implementation. >>>>>> To be safe the JDI & JDWP tests have to be run as well. It is well covered by the tier-5. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 4/9/20 21:46, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this change: >>>>>>> >>>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >>>>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/ >>>>>>> >>>>>>> We've discussed to use Thread-Local Handshake in some JVMTI functions [1]. >>>>>>> This change is for monitor functions. It affects GetOwnedMonitorInfo(), GetOwnedMonitorStackDepthInfo(), GetCurrentContendedMonitor(). >>>>>>> >>>>>>> It passed tests on submit repo (mach5-one-ysuenaga-JDK-8242425-20200410-0228-10075639), and also I confirmed to pass following tests: >>>>>>> >>>>>>> ?- serviceability/jvmti/GetOwnedMonitorInfo >>>>>>> ?- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>>>> ?- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>>>> ?- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html >>>>>> >>>> >> From alexey.menkov at oracle.com Tue Apr 21 01:02:35 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 20 Apr 2020 18:02:35 -0700 Subject: RFR(XS) 8242789: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with 'JShellToolProvider' missing from stdout/stderr In-Reply-To: <9108e173-6c21-4f5c-11ae-9ecd3d342af0@oracle.com> References: <0f377e45-63bc-8352-c9b6-984578a706d2@oracle.com> <36d509ff-b48e-2961-c63f-44f5fdb796b7@oracle.com> <9108e173-6c21-4f5c-11ae-9ecd3d342af0@oracle.com> Message-ID: +1 --alex On 04/20/2020 12:03, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > LGTM > > Thanks, > Serguei > > > On 4/20/20 10:46, Chris Plummer wrote: >> Ping. This is a very simple change. >> >> thanks, >> >> Chris >> >> On 4/17/20 10:30 AM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8242789 >>> http://cr.openjdk.java.net/~cjplummer/8242789/webrev.00 >>> >>> JShellHeapDumpTest.java has two variants, one that does a short 2 >>> second sleep after launching the jshell process (the main >>> JShellHeapDumpTest.java test does this) and the other that does no >>> sleep (HeapDumpTestWithActiveProcess.java does this by invoking >>> JShellHeapDumpTest.java with the "nosleep" argument). >>> >>> The reason for the 2 second sleep is to get the jshell process into a >>> steady state so JDK-8231634 [1] doesn't turn up when using SA on the >>> jshell process. I added the sleep instead of problem listing >>> JShellHeapDumpTest.java since it is a useful test even with the sleep >>> in place. HeapDumpTestWithActiveProcess.java was added so we still >>> had a test to reproduce JDK-8231634 [1], and was problem listed >>> immediately. However, another side affect of not sleeping is >>> sometimes SA requests the thread dump of the jshell process before >>> jshell enters its main thread. Thus the test can't find the >>> "JShellToolProvider" symbol in the thread dump. The fix is to simply >>> not require the symbol to be present when in "nosleep" mode. >>> >>> thanks, >>> >>> Chris >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8231634 >>> >> >> > From david.holmes at oracle.com Tue Apr 21 03:01:42 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Apr 2020 13:01:42 +1000 Subject: RFR: JDK-8242943 Fix all remaining unchecked warnings in jdk.hotspot.agent In-Reply-To: References: Message-ID: <987fa5f2-0ad3-6e61-a505-d436d347f512@oracle.com> Hi Magnus, That all seems reasonable to me. Thanks, David ----- On 16/04/2020 10:47 pm, Magnus Ihse Bursie wrote: > This is the final part of removing all warnings from the build of > jdk.hotspot.agent. This patch includes a number of non-trivial fixes for > the few remaining unchecked warnings. > > The good news is that with this fix (and after the recent removal of > Nashorn and rmic), the JDK build is finally complete free from warnings > for the first time ever! EPIC!!!!!1!!! :-) > > The bad news is that this patch is probably the most complex of all I've > posted so far. :-/ > > I'll break down the changes in four groups: > > * ConstMethod superclass issue > > ConstMethod current extends VMObject. However, it is treated as a > Metadata (Metadata is a subtype of VMObject). For instance, this code > appears in Metadata.java: > ? metadataConstructor.addMapping("ConstMethod", ConstMethod.class); > > I believe it is just an oversight that ConstMethod does not also extend > Metadata like the rest of the classes added to the metadataConstructor > mapping, one which has not been caught without the extra type safety > given by generics. > > * ProfileData casting > > In several places, a ProfileData item is extracted from a collection, > its type checked with instanceof, and then acted on accordingly. (Yeah, > nice and clean OOP abstraction at work! :-)) > > This works well most of the time, but when casting to ReceiverTypeData > or CallTypeDataInterface, the type include generic parametrisation, so > it needs to be cast to e.g. ReceiverTypeData. > Unfortunately, this cannot be verified using instanceof, due to generic > type erasure, and thus the compiler considers this an unchecked cast. > (At least, this is my understanding of what is happening.) As far as I > can tell, this is legitimate code, and the only way to really handle > this (barring a more extensive rewrite) is to disable the warning for > these cases. > > * Generification of the InstanceConstructor hierarchy > > I have properly generified the InstanceConstructor hierarchy, with the > VirtualConstructor, StaticBaseConstructor and VirtualBaseConstructor > subclasses. (And also the related helper class VMObjectFactory.) > > Most of it turned out OK (and with improved type safety), but there was > one piece of code that is a bit unfortunate. In VirtualBaseConstructor, > we have the following: > ??????????? @SuppressWarnings("unchecked") > ??????????? Class lookedUpClass = (Class T>)Class.forName(packageName + "." + superType.getName()); > ??????????? c = lookedUpClass; > > That is, we send in a name for a class and assumes that it will resolve > to a subtype of T, but there is no way to enforce this with type safety. > I have verified all current callers to the constructor so that they all > abide to this rule (of course, otherwise the code would not have worked, > but I checked it anyway). The alternative to suppressing the warning is > to redesign the entire API, so we do not send in a class name, but > instead a Class, and use that to extract the name instead. > At this point, I don't find it worth it. This is, after all, no worse > than it was before. > > * SortableTableModel and TableModelComparator > > This one was quite messy. The tables are being used in quite different > ways in different places, which made it hard to generify in a good way. > A lot of it revolves around keeping the data as Objects and casting it > to a known type. (Some of this behavior comes from the fact that they > extend old Swing classes which does this.) I've tried to tighten it up > as much as possible by introducing increased type safety by > generification, but in the end, it was not fully possible to do without > a major surgery of the entire class structure. As above, most of it > turned out OK, but not all. > > The tricky one here is the helper TableModelComparator. This one took me > a while to wrap my head around. It implements Comparator, but the > compare() method takes "rows" from the model, which are just expressed > as Objects, and left to subclasses to define differently. For one of the > subclasses it uses the type T that the TableModel is created around, but > in other it uses an independent domain model. :-/ Anyway. The compare() > method then extracts data for the individual columns of each row using > the method getValueForColumn(), and compare them pairwise. This data > from the rows are supposed to implement Comparable. > > In the end, I think I got it pretty OK, but I'm still an apprentice when > it comes to generics black magic. The subclasses of TableModelComparator > want to return different objects from getValueForColumn() for different > columns in the row, like Long or String. They are all Comparable, but > String is Comparable and Long is Comparable. So I needed > to specify the abstract method as returning Comparable, since > Comparable is not Comparable. > > But then, for reasons that I do not fully fathom, I could not specify > > Comparable o1 = getValueForColumn(row1, columns[i]); > Comparable o2 = getValueForColumn(row2, columns[i]); > int result = o1.compareTo(o2); > > because the compiler did not accept the call to compareTo(). > > I did try to sacrifice a black rooster at midnight and walking backwards > in a circle three time, to no avail. Maybe the problem was that it was > not full moon or that I have no cat. In the end, I casted o1 and o2 to > Comparable and suppressed the warning for that cast. > > If anyone knows what rituals I need to perform to make this work, or -- > even better -- how to fix the code properly, please let me know! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242943 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8242943-SA-final-unchecked-warnings/webrev.01 > > > /Magnus From daniil.x.titov at oracle.com Tue Apr 21 04:48:15 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 20 Apr 2020 21:48:15 -0700 Subject: 8231585: java/lang/management/ThreadMXBean/MaxDepthForThreadInfoTest.java fails with java.lang.NullPointerException In-Reply-To: <7287552a-4e6b-9a7b-991a-05db515a49cc@oracle.com> References: <902A52FD-B44F-47C3-8658-969D0CEA2671@oracle.com> <7287552a-4e6b-9a7b-991a-05db515a49cc@oracle.com> Message-ID: <7F5C14FA-05AA-4BF0-B52C-31D2227580AD@oracle.com> Hi David, Serguei, and Chris, Thank you for reviewing this change. The issue is not easy to reproduce. I tried to run the test (without the fix) with Graal on in Mach5 about 600 times and so far the failure didn't reproduce. I will continue running these tests in the next few days and will update the issue with the information about disappearing thread when it gets reproduced. Best regards, Daniil ?On 4/18/20, 6:56 AM, "David Holmes" wrote: Hi Daniil, On 18/04/2020 6:03 am, Daniil Titov wrote: > Please review the change that fixes intermittent failure of java/lang/management/ThreadMXBean/MaxDepthForThreadInfoTest.java > > As David noticed (thank you, David, for this analysis) there is no guarantee that all threads found by getAllThreadIds() are still alive by the time we call getThreadInfo() so we have to allow for null array entries. > > Testing: Mach5 tests with Graal on passed 300 times. Fix looks good - thanks. I think it would be informative to actually determine which thread(s) is disappearing (not as part of the test just as some diagnostic info to add to the JBS issue). Can you reproduce the failure easily? Thanks, David > [1] http://cr.openjdk.java.net/~dtitov/8231585/webrev.01/ > [2] https://bugs.openjdk.java.net/browse/JDK-8231585 > > Best regards, > Daniil > > From christoph.langer at sap.com Tue Apr 21 07:59:48 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 21 Apr 2020 07:59:48 +0000 Subject: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump In-Reply-To: References: <01361a9d-2855-db67-a176-73731fada08f@oracle.com> <0c687e55-ed91-e606-28a7-f9aef745ed8d@oracle.com> <490d58f7-7adc-00aa-b504-0ac284fe7eb5@oracle.com> <0343dfac-61f7-1b1c-ee96-bdee130578ad@oracle.com> Message-ID: Hi Ralf, I've just started a closer review of your change, based on your current webrev. I'm not done yet but hope I'll find the time to finish this in the next few days. However, as this patch seems in a quite good condition already and we're targeting JDK15, could you please start creating the required CSR to get it through the CSR process in parallel to the final review? Thanks Christoph > -----Original Message----- > From: Schmelter, Ralf > Sent: Montag, 20. April 2020 10:14 > To: Reingruber, Richard ; Ioi Lam > ; Langer, Christoph ; > Yasumasa Suenaga ; > serguei.spitsyn at oracle.com; hotspot-runtime-dev at openjdk.java.net > runtime > Cc: serviceability-dev at openjdk.java.net > Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap > dump > > Hi Richard, > > thanks for the review. I have incorporated your remarks into a new webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.2/ > > Some remarks to specific points: > > > ### src/hotspot/share/services/heapDumper.cpp > > 762: assert(_active, "Must be active"); > > > > It appears to me that the assertion would fail, if an error occurred creating > the CompressionBackend. > > You are supposed to check for errors after creating the DumpWriter (which > creates the CompressionBackend). And in case of an error, you directly > destruct the object. I've added a comment to make that clear. > > > 767: I think _current->in_used doesn't take the final 9 bytes into account > that are written in > > DumperSupport::end_of_dump() after the last dump segment has been > finished. > > You could call get_new_buffer() instead of the if clause. > > Wow, how did you found this? I've fixed it by making sure we flush the > DumpWriter before calling the deactivate method. > > > 1064: DumpWriter::DumpWriter() > > > > There doesn't seem to be enough error handling if _buffer cannot be > allocated. > > E.g. DumpWriter::write_raw() at line 1091 will enter an endless loop. > > As described above, this will not happen if we check for error after > constructing the DumpWriter. > > > ### src/java.base/share/native/libzip/zip_util.c > > 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() > performance wise. But have you > > measured the performance gain? In other words: is it worth it? :) > > This is not done for performance, but to make sure the allocation will not fail > midway during writing the dump. Maybe it is not worth it, though. > > > 1655: The result of deflateBound() seems to depend on the header > comment, which is not given > > here. Could this be an issue, because ZIP_GZip_Fully() can take a > comment? > > I've added a 1024 byte additional bytes to avoid the problem. > > > ### test/lib/jdk/test/lib/hprof/parser/Reader.java > > > > 93: is the created GzipRandomAccess instance closed somewhere? > > The object is not closed since it is still used by the Snapshot returned. > > Best regard, > Ralf > > > -----Original Message----- > From: Reingruber, Richard > Sent: Tuesday, 14 April 2020 10:30 > To: Schmelter, Ralf ; Ioi Lam > ; Langer, Christoph ; > Yasumasa Suenaga ; > serguei.spitsyn at oracle.com; hotspot-runtime-dev at openjdk.java.net > runtime > Cc: serviceability-dev at openjdk.java.net > Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap > dump > > Hi Ralf, > > thanks for providing this enhancement to parallel gzip-compress heap > dumps! > > I reckon it's safe to say that the coding is sophisticated. It would be awesome > if you could sketch > the idea of how HeapDumper, DumpWriter and CompressionBackend work > together to produce the gzipped > dump in a source code comment. Just enough to get started if somebody > should ever have to track down > a bug -- an unlikely event, I know ;) > > Please find the details of my review below. > > Thanks, Richard. > // Not Reviewer > > -- > > ### src/hotspot/share/services/diagnosticCommand.cpp > > 510 _gzip_level("-gz-level", "The compression level from 0 (store) to 9 > (best) when writing in gzipped format.", > 511 "INT", "FALSE", "1") { > > "FALSE" should be probably false. > > ### src/hotspot/share/services/diagnosticCommand.hpp > Ok. > > ### src/hotspot/share/services/heapDumper.cpp > > 390: Typo: initized > > 415: Typo: GZipComressor > > 477: Could you please add a comment, how the "HPROF BLOCKSIZE" > comment is helpful? > > 539: Member variables of WriteWork are missing the '_' prefix. > > 546: Just a comment: WriteWork::in_max is actually a compile time constant. > Would be nice if it could be > declared so. One could use templates for this, but then my favourite ide > (eclipse cdt) doesn't > show me references and call hierarchies anymore. So I don't think it is > worth it. > > 591: Typo: Removes the first element. Returns NULL is empty. > > 663: _writer, _compressor, _lock could be const. > > 762: assert(_active, "Must be active"); > > It appears to me that the assertion would fail, if an error occurred creating > the CompressionBackend. > > 767: I think _current->in_used doesn't take the final 9 bytes into account that > are written in > DumperSupport::end_of_dump() after the last dump segment has been > finished. > You could call get_new_buffer() instead of the if clause. > > 903: Typo: Check if we don not waste more than _max_waste > > 1064: DumpWriter::DumpWriter() > > There doesn't seem to be enough error handling if _buffer cannot be > allocated. > E.g. DumpWriter::write_raw() at line 1091 will enter an endless loop. > > 2409: A comment, why Shenandoah is not supported, would be good. > In general I'd say it is good and natural to use the GC work threads. > > ### src/hotspot/share/services/heapDumper.hpp > Ok. > > ### src/java.base/share/native/libzip/zip_util.c > > I'm not familiar with zlib, but here are my .02? :) > > 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() > performance wise. But have you > measured the performance gain? In other words: is it worth it? :) > > 1655: The result of deflateBound() seems to depend on the header > comment, which is not given > here. Could this be an issue, because ZIP_GZip_Fully() can take a > comment? > > 1658: deflateEnd() should not be called if deflateInit2Wrapper() failed. I think > this can lead > otherwise to a double free() call. > > ### > test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java > > 66: Maybe additionally check the exit value? > > 73: It's unclear to me, why this fails. Because the dump already exists? > Because the level is > invalid? Reading the comment I'd expect success, not failure. > > ### > test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestEpsilo > n.java > Ok. > > ### > test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestShen > andoah.java > Ok. > > ### > test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestZ.jav > a > Ok. > > ### test/lib/jdk/test/lib/hprof/parser/GzipRandomAccess.java > Ok. > > ### test/lib/jdk/test/lib/hprof/parser/HprofReader.java > Ok. > > ### test/lib/jdk/test/lib/hprof/parser/Reader.java > > 93: is the created GzipRandomAccess instance closed somewhere? From magnus.ihse.bursie at oracle.com Tue Apr 21 11:56:25 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Apr 2020 13:56:25 +0200 Subject: RFR: JDK-8242943 Fix all remaining unchecked warnings in jdk.hotspot.agent In-Reply-To: References: Message-ID: On 2020-04-20 21:19, Joe Darcy wrote: > Hello, > > On 4/16/2020 5:47 AM, Magnus Ihse Bursie wrote: > [snip] >> The tricky one here is the helper TableModelComparator. This one took >> me a while to wrap my head around. It implements Comparator, but the >> compare() method takes "rows" from the model, which are just >> expressed as Objects, and left to subclasses to define differently. >> For one of the subclasses it uses the type T that the TableModel is >> created around, but in other it uses an independent domain model. :-/ >> Anyway. The compare() method then extracts data for the individual >> columns of each row using the method getValueForColumn(), and compare >> them pairwise. This data from the rows are supposed to implement >> Comparable. >> >> In the end, I think I got it pretty OK, but I'm still an apprentice >> when it comes to generics black magic. The subclasses of >> TableModelComparator want to return different objects from >> getValueForColumn() for different columns in the row, like Long or >> String. They are all Comparable, but String is Comparable and >> Long is Comparable. So I needed to specify the abstract method >> as returning Comparable, since Comparable is not >> Comparable. >> >> But then, for reasons that I do not fully fathom, I could not specify >> >> Comparable o1 = getValueForColumn(row1, columns[i]); >> Comparable o2 = getValueForColumn(row2, columns[i]); >> int result = o1.compareTo(o2); >> >> because the compiler did not accept the call to compareTo(). >> >> I did try to sacrifice a black rooster at midnight and walking >> backwards in a circle three time, to no avail. Maybe the problem was >> that it was not full moon or that I have no cat. In the end, I casted >> o1 and o2 to Comparable and suppressed the warning for that >> cast. >> >> If anyone knows what rituals I need to perform to make this work, or >> -- even better -- how to fix the code properly, please let me know! > > A brief discussion of wildcards, ?. The meaning of a wildcard is some > particular unknown type, meeting the various? constraints from "? > extends" or "? super".? If there is no explicit constraint listed, it > is equivalent to "? extends Object". > > So the meaning of the code above is something > > Comparable o1 = getValueForColumn(row1, columns[i]); > Comparable o2 = getValueForColumn(row2, columns[i]); > > where S and T are two fresh, unrelated type variables. Concretely, > this means S and T could be, say, String and Integer so that is why a > call to o1.compareTo(o2) would not be accepted by the compiler since > Strings and Integer aren't comparable to each other. Ah, right, and compareTo -- in contrast with equals() -- only compares to objects of the same type. I think that's part of what confused me here. > > While two instances of "Comparable" are syntactically the same, > they don't represent the same type inside the compiler. > > In some cases, you can get around this issue by using a separate > method to capture the type variable and then use it more than once. A > technique we've used in the JDK is to have a pubic method with a > wildcards calling a private method using a type variable. I've looked > around for a few minutes and didn't find a concrete example in the > JDK, but they're in there. > > I haven't looked over the specific code here in much detail; the type > Comparable might to be the best you can do, but it isn't very > expressive since Object's aren't necessarily comparable. Thank you for taking time to explain this! /Magnus > > HTH, > > -Joe > From ralf.schmelter at sap.com Tue Apr 21 13:00:57 2020 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 21 Apr 2020 13:00:57 +0000 Subject: RFR (S) 8243244: CSR Add option to jcmd to write a gzipped heap dump Message-ID: Hi, I need a review for the following CSR: https://bugs.openjdk.java.net/browse/JDK-8243244 It describes the two additional options added to the GC.heap_dump command to support gzipped heap dumps. Best regards, Ralf From coleen.phillimore at oracle.com Tue Apr 21 20:12:44 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 Apr 2020 16:12:44 -0400 Subject: RFR (M) Close alignment gaps in InstanceKlass Message-ID: Summary: moved fields around and some constant fields into ConstantPool This is a simple change except that I moved some constant fields from InstanceKlass into the constant pool so they can be shared read-only in the CDS archive.? There are associated repercussions in SA and JVMCI, so please look at these changes.? Also moved similarly sized fields together in the class so there's less likelihood of introducing gaps in future InstanceKlass changes. InstanceKlass is reduced from 544 to 520 bytes in a simple Hello World class. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8238048 Tested with tier1-6. Thanks, Coleen From chris.plummer at oracle.com Tue Apr 21 20:41:53 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 21 Apr 2020 13:41:53 -0700 Subject: RFR (M) Close alignment gaps in InstanceKlass In-Reply-To: References: Message-ID: Hi Coleen, The SA changes look good. BTW, I've already made the TestIntConstant.java change in the Loom project. InstanceKlass::_misc_is_unsafe_anonymous was already changed to "8" in loom. You might want to sync up with Ron to make sure you aren't making conflicting changes in this area. Your code looks like: ?249?? enum { ?250???? _misc_rewritten?????????????????????????? = 1 << 0,? // methods rewritten. ?251???? _misc_has_nonstatic_fields??????????????? = 1 << 1,? // for sizing with UseCompressedOops ?252???? _misc_should_verify_class???????????????? = 1 << 2,? // allow caching of preverification ?253???? _misc_is_unsafe_anonymous???????????????? = 1 << 3,? // has embedded _unsafe_anonymous_host field ?254???? _misc_is_contended??????????????????????? = 1 << 4,? // marked with contended annotation Loom looks like: ? static const unsigned _misc_kind_field_size = 0; ... ? // Start after _misc_kind field. ? enum { ??? _misc_rewritten?????????????????????????? = 1 << (_misc_kind_field_size + 0),? // methods rewritten. ??? _misc_has_nonstatic_fields??????????????? = 1 << (_misc_kind_field_size + 1),? // for sizing with UseCompressedOops ??? _misc_should_verify_class???????????????? = 1 << (_misc_kind_field_size + 2),? // allow caching of preverification ??? _misc_is_unsafe_anonymous???????????????? = 1 << (_misc_kind_field_size + 3),? // has embedded _unsafe_anonymous_host field ??? _misc_is_contended??????????????????????? = 1 << (_misc_kind_field_size + 4),? // marked with contended annotation ... At the very least this is a merge conflict that loom will need to deal with and it would help to know about in advance (Alan normally does the merges). thanks, Chris On 4/21/20 1:12 PM, coleen.phillimore at oracle.com wrote: > Summary: moved fields around and some constant fields into ConstantPool > > This is a simple change except that I moved some constant fields from > InstanceKlass into the constant pool so they can be shared read-only > in the CDS archive.? There are associated repercussions in SA and > JVMCI, so please look at these changes.? Also moved similarly sized > fields together in the class so there's less likelihood of introducing > gaps in future InstanceKlass changes. > > InstanceKlass is reduced from 544 to 520 bytes in a simple Hello World > class. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8238048 > > Tested with tier1-6. > > Thanks, > Coleen > > From coleen.phillimore at oracle.com Tue Apr 21 21:36:32 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 Apr 2020 17:36:32 -0400 Subject: RFR (M) Close alignment gaps in InstanceKlass In-Reply-To: References: Message-ID: <269efe5a-3cd2-714f-16c3-f6bd46a60b4d@oracle.com> On 4/21/20 4:41 PM, Chris Plummer wrote: > Hi Coleen, > > The SA changes look good. BTW, I've already made the > TestIntConstant.java change in the Loom project. > InstanceKlass::_misc_is_unsafe_anonymous was already changed to "8" in > loom. You might want to sync up with Ron to make sure you aren't > making conflicting changes in this area. Your code looks like: > > ?249?? enum { > ?250???? _misc_rewritten?????????????????????????? = 1 << 0,? // > methods rewritten. > ?251???? _misc_has_nonstatic_fields??????????????? = 1 << 1,? // for > sizing with UseCompressedOops > ?252???? _misc_should_verify_class???????????????? = 1 << 2,? // allow > caching of preverification > ?253???? _misc_is_unsafe_anonymous???????????????? = 1 << 3,? // has > embedded _unsafe_anonymous_host field > ?254???? _misc_is_contended??????????????????????? = 1 << 4,? // > marked with contended annotation > > Loom looks like: > > ? static const unsigned _misc_kind_field_size = 0; > ... > ? // Start after _misc_kind field. > ? enum { > ??? _misc_rewritten?????????????????????????? = 1 << > (_misc_kind_field_size + 0),? // methods rewritten. > ??? _misc_has_nonstatic_fields??????????????? = 1 << > (_misc_kind_field_size + 1),? // for sizing with UseCompressedOops > ??? _misc_should_verify_class???????????????? = 1 << > (_misc_kind_field_size + 2),? // allow caching of preverification > ??? _misc_is_unsafe_anonymous???????????????? = 1 << > (_misc_kind_field_size + 3),? // has embedded _unsafe_anonymous_host > field > ??? _misc_is_contended??????????????????????? = 1 << > (_misc_kind_field_size + 4),? // marked with contended annotation > ... > > At the very least this is a merge conflict that loom will need to deal > with and it would help to know about in advance (Alan normally does > the merges). It looks like there are other changes in loom that motivated changing it like this.? Why is misc_kind_field_size = 0? Did loom add more misc_flags ?? It turns out that there are plenty of available flags in the access_flags if more are needed. Thank you for looking at the SA changes. Coelen > > thanks, > > Chris > > On 4/21/20 1:12 PM, coleen.phillimore at oracle.com wrote: >> Summary: moved fields around and some constant fields into ConstantPool >> >> This is a simple change except that I moved some constant fields from >> InstanceKlass into the constant pool so they can be shared read-only >> in the CDS archive.? There are associated repercussions in SA and >> JVMCI, so please look at these changes. Also moved similarly sized >> fields together in the class so there's less likelihood of >> introducing gaps in future InstanceKlass changes. >> >> InstanceKlass is reduced from 544 to 520 bytes in a simple Hello >> World class. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8238048 >> >> Tested with tier1-6. >> >> Thanks, >> Coleen >> >> > From coleen.phillimore at oracle.com Tue Apr 21 21:45:38 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 Apr 2020 17:45:38 -0400 Subject: RFR (M) Close alignment gaps in InstanceKlass In-Reply-To: References: Message-ID: <515a359f-d4a1-785d-4aa9-ae39c7074438@oracle.com> On 4/21/20 4:41 PM, Chris Plummer wrote: > Hi Coleen, > > The SA changes look good. BTW, I've already made the > TestIntConstant.java change in the Loom project. > InstanceKlass::_misc_is_unsafe_anonymous was already changed to "8" in > loom. You might want to sync up with Ron to make sure you aren't > making conflicting changes in this area. Your code looks like: > > ?249?? enum { > ?250???? _misc_rewritten?????????????????????????? = 1 << 0,? // > methods rewritten. > ?251???? _misc_has_nonstatic_fields??????????????? = 1 << 1,? // for > sizing with UseCompressedOops > ?252???? _misc_should_verify_class???????????????? = 1 << 2,? // allow > caching of preverification > ?253???? _misc_is_unsafe_anonymous???????????????? = 1 << 3,? // has > embedded _unsafe_anonymous_host field > ?254???? _misc_is_contended??????????????????????? = 1 << 4,? // > marked with contended annotation > > Loom looks like: > > ? static const unsigned _misc_kind_field_size = 0; > ... > ? // Start after _misc_kind field. > ? enum { > ??? _misc_rewritten?????????????????????????? = 1 << > (_misc_kind_field_size + 0),? // methods rewritten. > ??? _misc_has_nonstatic_fields??????????????? = 1 << > (_misc_kind_field_size + 1),? // for sizing with UseCompressedOops > ??? _misc_should_verify_class???????????????? = 1 << > (_misc_kind_field_size + 2),? // allow caching of preverification > ??? _misc_is_unsafe_anonymous???????????????? = 1 << > (_misc_kind_field_size + 3),? // has embedded _unsafe_anonymous_host > field > ??? _misc_is_contended??????????????????????? = 1 << > (_misc_kind_field_size + 4),? // marked with contended annotation > ... > > At the very least this is a merge conflict that loom will need to deal > with and it would help to know about in advance (Alan normally does > the merges). Actually I just had a look at the loom instanceKlass.hpp and this change helps that. Loom adds a kind of InstanceKlass, so changed the field to a u1 as I have done. This will clean up loom too. Thanks, Coleen > > thanks, > > Chris > > On 4/21/20 1:12 PM, coleen.phillimore at oracle.com wrote: >> Summary: moved fields around and some constant fields into ConstantPool >> >> This is a simple change except that I moved some constant fields from >> InstanceKlass into the constant pool so they can be shared read-only >> in the CDS archive.? There are associated repercussions in SA and >> JVMCI, so please look at these changes. Also moved similarly sized >> fields together in the class so there's less likelihood of >> introducing gaps in future InstanceKlass changes. >> >> InstanceKlass is reduced from 544 to 520 bytes in a simple Hello >> World class. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8238048 >> >> Tested with tier1-6. >> >> Thanks, >> Coleen >> >> > From chris.plummer at oracle.com Tue Apr 21 23:07:54 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 21 Apr 2020 16:07:54 -0700 Subject: RFR(XS) 8243210: ClhsdbScanOops fails with NullPointerException in FileMapHeader.inCopiedVtableSpace Message-ID: <0f6811e4-f4c8-d87a-aedc-17350e899d34@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8243210 http://cr.openjdk.java.net/~cjplummer/8243210/webrev.01/index.html Description is in the bug. Hopefully this is the last in a series of about 6 bugs being addressed that finally lets us get this test off the problem list for all platforms. thanks, Chris From linzang at tencent.com Wed Apr 22 00:21:33 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Wed, 22 Apr 2020 00:21:33 +0000 Subject: RFR(L): 8215624: add parallel heap inspection support for jmap histo(G1) In-Reply-To: References: Message-ID: Dear all, May I ask you help to review? This RFR has been there for quite a while. Thanks! BRs, Lin ?> On 2020/3/16, 5:18 PM, "linzang(??)" wrote:> > Just update a new path, my preliminary measure show about 3.5x speedup of jmap histo on a nearly full 4GB G1 heap (8-core platform with parallel thread number set to 4). > webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_02/ > bug: https://bugs.openjdk.java.net/browse/JDK-8215624 > CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 > BRs, > Lin > > On 2020/3/2, 9:56 PM, "linzang(??)" wrote: > > > > Dear all, > > Let me try to ease the reviewing work by some explanation :P > > The patch's target is to speed up jmap -histo for heap iteration, from my experience it is necessary for large heap investigation. E.g in bigData scenario I have tried to conduct jmap -histo against 180GB heap, it does take quite a while. > > And if my understanding is corrent, even the jmap -histo without "live" option does heap inspection with heap lock acquired. so it is very likely to block mutator thread in allocation-sensitive scenario. I would say the faster the heap inspection does, the shorter the mutator be blocked. This is parallel iteration for jmap is necessary. > > I think the parallel heap inspection should be applied to all kind of heap. However, consider the heap layout are different for GCs, much time is required to understand all kinds of the heap layout to make the whole change. IMO, It is not wise to have a huge patch for the whole solution at once, and it is even harder to review it. So I plan to implement it incrementally, the first patch (this one) is going to confirm the implemention detail of how jmap accept the new option, passes it to attachListener of the jvm process and then how to make the parallel inspection closure be generic enough to make it easy to extend to different heap layout. And also how to implement the heap inspection in specific gc's heap. This patch use G1's heap as the begining. > > This patch actually do several things: > > 1. Add an option "parallelThreadNum=" to jmap -histo, the default behavior is to set N to 0, means let's JVM decide how many threads to use for heap inspection. Set this option to 1 will disable parallel heap inspection. (more details in CSR: https://bugs.openjdk.java.net/browse/JDK-8239290) > > 2. Make a change in how Jmap passing arguments, changes in http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html, originally it pass options as separate arguments to attachListener, this patch change to that all options be compose to a single string. So the arg_count_max in attachListener.hpp do not need to be changed, and hence avoid the compatibility issue, as disscussed at https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027334.html > > 3. Add an abstract class ParHeapInspectTask in heapInspection.hpp / heapInspection.cpp, It's work(uint worker_id) method prepares the data structure (KlassInfoTable) need for every parallel worker thread, and then call do_object_iterate_parallel() which is heap specific implementation. I also added some machenism in KlassInfoTable to support parallel iteration, such as merge(). > > 4. In specific heap (G1 in this patch), create a subclass of ParHeapInspectTask, implement the do_object_iterate_parallel() for parallel heap inspection. For G1, it simply invoke g1CollectedHeap's object_iterate_parallel(). > > 5. Add related test. > > 6. it may be easy to extend this patch for other kinds of heap by creating subclass of ParHeapInspectTask and implement the do_object_iterate_parallel(). > > > > Hope these info could help on code review and initate the discussion :-) > > Thanks! > > > > BRs, > > Lin > > >On 2020/2/19, 9:40 AM, "linzang(??)" wrote:. > > > > > > Re-post this RFR with correct enhancement number to make it trackable. > > > please ignore the previous wrong post. sorry for troubles. > > > > > > webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/ > > > Hi bug: https://bugs.openjdk.java.net/browse/JDK-8215624 > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 > > > -------------- > > > Lin > > > >Hi Lin, > > > > > > > >Could you, please, re-post your RFR with the right enhancement number in > > > >the message subject? > > > >It will be more trackable this way. > > > > > > > >Thanks, > > > >Serguei > > > > > > > > > > > >On 2/17/20 10:29 PM, linzang(??) wrote: > > > >> Dear David, > > > >> Thanks a lot! > > > >> I have updated the refined code to http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_01/. > > > >> IMHO the parallel heap inspection can be extended to all kinds of heap as long as the heap layout can support parallel iteration. > > > >> Maybe we can firstly use this webrev to discuss how to implement it, because I am not sure my current implementation is an appropriate way to communicate with collectedHeap, then we can extend the solution to other kinds of heap. > > > >> > > > >> Thanks, > > > >> -------------- > > > >> Lin > > > >>> Hi Lin, > > > >>> > > > >>> Adding in hotspot-gc-dev as they need to see how this interacts with GC > > > >>> worker threads, and whether it needs to be extended beyond G1. > > > >>> > > > >>> I happened to spot one nit when browsing: > > > >>> > > > >>> src/hotspot/share/gc/shared/collectedHeap.hpp > > > >>> > > > >>> + virtual bool run_par_heap_inspect_task(KlassInfoTable* cit, > > > >>> + BoolObjectClosure* filter, > > > >>> + size_t* missed_count, > > > >>> + size_t thread_num) { > > > >>> + return NULL; > > > >>> > > > >>> s/NULL/false/ > > > >>> > > > >>> Cheers, > > > >>> David > > > >>> > > > >>> On 18/02/2020 2:15 pm, linzang(??) wrote: > > > >>>> Dear All, > > > >>>> May I ask your help to review the follow changes: > > > >>>> webrev: > > > >>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_00/ > > > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 > > > >>>> related CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 > > > >>>> This patch enable parallel heap inspection of G1 for jmap histo. > > > >>>> my simple test shown it can speed up 2x of jmap -histo with > > > >>>> parallelThreadNum set to 2 for heap at ~500M on 4-core platform. > > > >>>> > > > >>>> ------------------------------------------------------------------------ > > > >>>> BRs, > > > >>>> Lin > > > >> > > > > > From serguei.spitsyn at oracle.com Wed Apr 22 01:35:28 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Apr 2020 18:35:28 -0700 Subject: RFR(XS) 8243210: ClhsdbScanOops fails with NullPointerException in FileMapHeader.inCopiedVtableSpace In-Reply-To: <0f6811e4-f4c8-d87a-aedc-17350e899d34@oracle.com> References: <0f6811e4-f4c8-d87a-aedc-17350e899d34@oracle.com> Message-ID: Hi Chris, It looks reasonable. Thanks, Serguei On 4/21/20 16:07, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8243210 > http://cr.openjdk.java.net/~cjplummer/8243210/webrev.01/index.html > > Description is in the bug. Hopefully this is the last in a series of > about 6 bugs being addressed that finally lets us get this test off > the problem list for all platforms. > > thanks, > > Chris From dean.long at oracle.com Wed Apr 22 01:51:19 2020 From: dean.long at oracle.com (Dean Long) Date: Tue, 21 Apr 2020 18:51:19 -0700 Subject: RFR (M) Close alignment gaps in InstanceKlass In-Reply-To: References: Message-ID: <5a8317cb-dcdd-1fc5-7174-17304d75345a@oracle.com> Hi Coleen.? The JVMCI changes look OK.? It looks like there is a Graal unittest that covers getSourceFileName, but those tests don't always get run.? If it's not too much trouble, could you look into enabling getSourceFileName() testing in test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java ?? It's currently on the "untested" list. thanks, dl On 4/21/20 1:12 PM, coleen.phillimore at oracle.com wrote: > Summary: moved fields around and some constant fields into ConstantPool > > This is a simple change except that I moved some constant fields from > InstanceKlass into the constant pool so they can be shared read-only > in the CDS archive.? There are associated repercussions in SA and > JVMCI, so please look at these changes.? Also moved similarly sized > fields together in the class so there's less likelihood of introducing > gaps in future InstanceKlass changes. > > InstanceKlass is reduced from 544 to 520 bytes in a simple Hello World > class. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8238048 > > Tested with tier1-6. > > Thanks, > Coleen > > From stefan.karlsson at oracle.com Wed Apr 22 09:11:21 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 22 Apr 2020 11:11:21 +0200 Subject: RFR(L): 8215624: add parallel heap inspection support for jmap histo(G1) In-Reply-To: References: Message-ID: <71b02ca4-2972-b7cd-1a52-3bc454adbf75@oracle.com> Hi Lin, I took a look at this earlier and saw that the heap inspection code is strongly coupled with the CollectedHeap and G1CollectedHeap. I'd prefer if we'd abstract this away, so that the GCs only provide a "parallel object iteration" interface, and the heap inspection code is kept elsewhere. I started experimenting with doing that, but other higher-priority (to me) tasks have had to take precedence. I've uploaded my work-in-progress / proof-of-concept: ?https://cr.openjdk.java.net/~stefank/8215624/webrev.01.delta/ ?https://cr.openjdk.java.net/~stefank/8215624/webrev.01/ The current code doesn't handle the lifecycle (deletion) of the ParallelObjectIterators. There's also code left unimplemented in around CollectedHeap::run_task. However, I think this could work as a basis to pull out the heap inspection code out of the GCs. Thanks, StefanK On 2020-04-22 02:21, linzang(??) wrote: > Dear all, > May I ask you help to review? This RFR has been there for quite a while. > Thanks! > > BRs, > Lin > > ?> On 2020/3/16, 5:18 PM, "linzang(??)" wrote:> > >> Just update a new path, my preliminary measure show about 3.5x speedup of jmap histo on a nearly full 4GB G1 heap (8-core platform with parallel thread number set to 4). >> webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_02/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> BRs, >> Lin >> > On 2020/3/2, 9:56 PM, "linzang(??)" wrote: >> > >> > Dear all, >> > Let me try to ease the reviewing work by some explanation :P >> > The patch's target is to speed up jmap -histo for heap iteration, from my experience it is necessary for large heap investigation. E.g in bigData scenario I have tried to conduct jmap -histo against 180GB heap, it does take quite a while. >> > And if my understanding is corrent, even the jmap -histo without "live" option does heap inspection with heap lock acquired. so it is very likely to block mutator thread in allocation-sensitive scenario. I would say the faster the heap inspection does, the shorter the mutator be blocked. This is parallel iteration for jmap is necessary. >> > I think the parallel heap inspection should be applied to all kind of heap. However, consider the heap layout are different for GCs, much time is required to understand all kinds of the heap layout to make the whole change. IMO, It is not wise to have a huge patch for the whole solution at once, and it is even harder to review it. So I plan to implement it incrementally, the first patch (this one) is going to confirm the implemention detail of how jmap accept the new option, passes it to attachListener of the jvm process and then how to make the parallel inspection closure be generic enough to make it easy to extend to different heap layout. And also how to implement the heap inspection in specific gc's heap. This patch use G1's heap as the begining. >> > This patch actually do several things: >> > 1. Add an option "parallelThreadNum=" to jmap -histo, the default behavior is to set N to 0, means let's JVM decide how many threads to use for heap inspection. Set this option to 1 will disable parallel heap inspection. (more details in CSR: https://bugs.openjdk.java.net/browse/JDK-8239290) >> > 2. Make a change in how Jmap passing arguments, changes in http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html, originally it pass options as separate arguments to attachListener, this patch change to that all options be compose to a single string. So the arg_count_max in attachListener.hpp do not need to be changed, and hence avoid the compatibility issue, as disscussed at https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027334.html >> > 3. Add an abstract class ParHeapInspectTask in heapInspection.hpp / heapInspection.cpp, It's work(uint worker_id) method prepares the data structure (KlassInfoTable) need for every parallel worker thread, and then call do_object_iterate_parallel() which is heap specific implementation. I also added some machenism in KlassInfoTable to support parallel iteration, such as merge(). >> > 4. In specific heap (G1 in this patch), create a subclass of ParHeapInspectTask, implement the do_object_iterate_parallel() for parallel heap inspection. For G1, it simply invoke g1CollectedHeap's object_iterate_parallel(). >> > 5. Add related test. >> > 6. it may be easy to extend this patch for other kinds of heap by creating subclass of ParHeapInspectTask and implement the do_object_iterate_parallel(). >> > >> > Hope these info could help on code review and initate the discussion :-) >> > Thanks! >> > >> > BRs, >> > Lin >> > >On 2020/2/19, 9:40 AM, "linzang(??)" wrote:. >> > > >> > > Re-post this RFR with correct enhancement number to make it trackable. >> > > please ignore the previous wrong post. sorry for troubles. >> > > >> > > webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/ >> > > Hi bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > -------------- >> > > Lin >> > > >Hi Lin, > > > > > >> > > >Could you, please, re-post your RFR with the right enhancement number in >> > > >the message subject? >> > > >It will be more trackable this way. >> > > > >> > > >Thanks, >> > > >Serguei >> > > > >> > > > >> > > >On 2/17/20 10:29 PM, linzang(??) wrote: >> > > >> Dear David, >> > > >> Thanks a lot! >> > > >> I have updated the refined code to http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_01/. >> > > >> IMHO the parallel heap inspection can be extended to all kinds of heap as long as the heap layout can support parallel iteration. >> > > >> Maybe we can firstly use this webrev to discuss how to implement it, because I am not sure my current implementation is an appropriate way to communicate with collectedHeap, then we can extend the solution to other kinds of heap. >> > > >> >> > > >> Thanks, >> > > >> -------------- >> > > >> Lin >> > > >>> Hi Lin, >> > > >>> >> > > >>> Adding in hotspot-gc-dev as they need to see how this interacts with GC >> > > >>> worker threads, and whether it needs to be extended beyond G1. >> > > >>> >> > > >>> I happened to spot one nit when browsing: >> > > >>> >> > > >>> src/hotspot/share/gc/shared/collectedHeap.hpp >> > > >>> >> > > >>> + virtual bool run_par_heap_inspect_task(KlassInfoTable* cit, >> > > >>> + BoolObjectClosure* filter, >> > > >>> + size_t* missed_count, >> > > >>> + size_t thread_num) { >> > > >>> + return NULL; >> > > >>> >> > > >>> s/NULL/false/ >> > > >>> >> > > >>> Cheers, >> > > >>> David > > > > >>> >> > > >>> On 18/02/2020 2:15 pm, linzang(??) wrote: >> > > >>>> Dear All, >> > > >>>> May I ask your help to review the follow changes: >> > > >>>> webrev: >> > > >>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_00/ >> > > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > >>>> related CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > >>>> This patch enable parallel heap inspection of G1 for jmap histo. >> > > >>>> my simple test shown it can speed up 2x of jmap -histo with >> > > >>>> parallelThreadNum set to 2 for heap at ~500M on 4-core platform. >> > > >>>> >> > > >>>> ------------------------------------------------------------------------ >> > > >>>> BRs, >> > > >>>> Lin >> > > >> > >> > > > > > > From linzang at tencent.com Wed Apr 22 09:28:05 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Wed, 22 Apr 2020 09:28:05 +0000 Subject: RFR(L): 8215624: add parallel heap inspection support for jmap histo(G1)(Internet mail) In-Reply-To: <71b02ca4-2972-b7cd-1a52-3bc454adbf75@oracle.com> References: <71b02ca4-2972-b7cd-1a52-3bc454adbf75@oracle.com> Message-ID: <0A9D9FD9-9E18-4EC2-8379-6A2D3A4B388D@tencent.com> Dear Stefan, Thanks a lot! I agree with you to decouple the heap inspection code with GC's. I will start from your POC code, may discuss with you later. BRs, Lin ?On 2020/4/22, 5:14 PM, "Stefan Karlsson" wrote: Hi Lin, I took a look at this earlier and saw that the heap inspection code is strongly coupled with the CollectedHeap and G1CollectedHeap. I'd prefer if we'd abstract this away, so that the GCs only provide a "parallel object iteration" interface, and the heap inspection code is kept elsewhere. I started experimenting with doing that, but other higher-priority (to me) tasks have had to take precedence. I've uploaded my work-in-progress / proof-of-concept: https://cr.openjdk.java.net/~stefank/8215624/webrev.01.delta/ https://cr.openjdk.java.net/~stefank/8215624/webrev.01/ The current code doesn't handle the lifecycle (deletion) of the ParallelObjectIterators. There's also code left unimplemented in around CollectedHeap::run_task. However, I think this could work as a basis to pull out the heap inspection code out of the GCs. Thanks, StefanK On 2020-04-22 02:21, linzang(??) wrote: > Dear all, > May I ask you help to review? This RFR has been there for quite a while. > Thanks! > > BRs, > Lin > > > On 2020/3/16, 5:18 PM, "linzang(??)" wrote:> > >> Just update a new path, my preliminary measure show about 3.5x speedup of jmap histo on a nearly full 4GB G1 heap (8-core platform with parallel thread number set to 4). >> webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_02/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> BRs, >> Lin >> > On 2020/3/2, 9:56 PM, "linzang(??)" wrote: >> > >> > Dear all, >> > Let me try to ease the reviewing work by some explanation :P >> > The patch's target is to speed up jmap -histo for heap iteration, from my experience it is necessary for large heap investigation. E.g in bigData scenario I have tried to conduct jmap -histo against 180GB heap, it does take quite a while. >> > And if my understanding is corrent, even the jmap -histo without "live" option does heap inspection with heap lock acquired. so it is very likely to block mutator thread in allocation-sensitive scenario. I would say the faster the heap inspection does, the shorter the mutator be blocked. This is parallel iteration for jmap is necessary. >> > I think the parallel heap inspection should be applied to all kind of heap. However, consider the heap layout are different for GCs, much time is required to understand all kinds of the heap layout to make the whole change. IMO, It is not wise to have a huge patch for the whole solution at once, and it is even harder to review it. So I plan to implement it incrementally, the first patch (this one) is going to confirm the implemention detail of how jmap accept the new option, passes it to attachListener of the jvm process and then how to make the parallel inspection closure be generic enough to make it easy to extend to different heap layout. And also how to implement the heap inspection in specific gc's heap. This patch use G1's heap as the begining. >> > This patch actually do several things: >> > 1. Add an option "parallelThreadNum=" to jmap -histo, the default behavior is to set N to 0, means let's JVM decide how many threads to use for heap inspection. Set this option to 1 will disable parallel heap inspection. (more details in CSR: https://bugs.openjdk.java.net/browse/JDK-8239290) >> > 2. Make a change in how Jmap passing arguments, changes in http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html, originally it pass options as separate arguments to attachListener, this patch change to that all options be compose to a single string. So the arg_count_max in attachListener.hpp do not need to be changed, and hence avoid the compatibility issue, as disscussed at https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027334.html >> > 3. Add an abstract class ParHeapInspectTask in heapInspection.hpp / heapInspection.cpp, It's work(uint worker_id) method prepares the data structure (KlassInfoTable) need for every parallel worker thread, and then call do_object_iterate_parallel() which is heap specific implementation. I also added some machenism in KlassInfoTable to support parallel iteration, such as merge(). >> > 4. In specific heap (G1 in this patch), create a subclass of ParHeapInspectTask, implement the do_object_iterate_parallel() for parallel heap inspection. For G1, it simply invoke g1CollectedHeap's object_iterate_parallel(). >> > 5. Add related test. >> > 6. it may be easy to extend this patch for other kinds of heap by creating subclass of ParHeapInspectTask and implement the do_object_iterate_parallel(). >> > >> > Hope these info could help on code review and initate the discussion :-) >> > Thanks! >> > >> > BRs, >> > Lin >> > >On 2020/2/19, 9:40 AM, "linzang(??)" wrote:. >> > > >> > > Re-post this RFR with correct enhancement number to make it trackable. >> > > please ignore the previous wrong post. sorry for troubles. >> > > >> > > webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/ >> > > Hi bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > -------------- >> > > Lin >> > > >Hi Lin, > > > > > >> > > >Could you, please, re-post your RFR with the right enhancement number in >> > > >the message subject? >> > > >It will be more trackable this way. >> > > > >> > > >Thanks, >> > > >Serguei >> > > > >> > > > >> > > >On 2/17/20 10:29 PM, linzang(??) wrote: >> > > >> Dear David, >> > > >> Thanks a lot! >> > > >> I have updated the refined code to http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_01/. >> > > >> IMHO the parallel heap inspection can be extended to all kinds of heap as long as the heap layout can support parallel iteration. >> > > >> Maybe we can firstly use this webrev to discuss how to implement it, because I am not sure my current implementation is an appropriate way to communicate with collectedHeap, then we can extend the solution to other kinds of heap. >> > > >> >> > > >> Thanks, >> > > >> -------------- >> > > >> Lin >> > > >>> Hi Lin, >> > > >>> >> > > >>> Adding in hotspot-gc-dev as they need to see how this interacts with GC >> > > >>> worker threads, and whether it needs to be extended beyond G1. >> > > >>> >> > > >>> I happened to spot one nit when browsing: >> > > >>> >> > > >>> src/hotspot/share/gc/shared/collectedHeap.hpp >> > > >>> >> > > >>> + virtual bool run_par_heap_inspect_task(KlassInfoTable* cit, >> > > >>> + BoolObjectClosure* filter, >> > > >>> + size_t* missed_count, >> > > >>> + size_t thread_num) { >> > > >>> + return NULL; >> > > >>> >> > > >>> s/NULL/false/ >> > > >>> >> > > >>> Cheers, >> > > >>> David > > > > >>> >> > > >>> On 18/02/2020 2:15 pm, linzang(??) wrote: >> > > >>>> Dear All, >> > > >>>> May I ask your help to review the follow changes: >> > > >>>> webrev: >> > > >>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_00/ >> > > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > >>>> related CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > >>>> This patch enable parallel heap inspection of G1 for jmap histo. >> > > >>>> my simple test shown it can speed up 2x of jmap -histo with >> > > >>>> parallelThreadNum set to 2 for heap at ~500M on 4-core platform. >> > > >>>> >> > > >>>> ------------------------------------------------------------------------ >> > > >>>> BRs, >> > > >>>> Lin >> > > >> > >> > > > > > > From coleen.phillimore at oracle.com Wed Apr 22 15:18:07 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 Apr 2020 11:18:07 -0400 Subject: RFR (M) Close alignment gaps in InstanceKlass In-Reply-To: <5a8317cb-dcdd-1fc5-7174-17304d75345a@oracle.com> References: <5a8317cb-dcdd-1fc5-7174-17304d75345a@oracle.com> Message-ID: Hi Dean, Thank you for looking at the JVMCI changes and the suggestion to add the test.? I did this and found a bug.? The new test is quite limited because there's no good test to see if a source file name can assertNotNull(type.getSourceFileName()), so I couldn't iterate through the list of loaded classes like the other tests in that file. http://cr.openjdk.java.net/~coleenp/2020/8238048.02.incr/webrev/index.html Thanks, Coleen On 4/21/20 9:51 PM, Dean Long wrote: > Hi Coleen.? The JVMCI changes look OK.? It looks like there is a Graal > unittest that covers getSourceFileName, but those tests don't always > get run.? If it's not too much trouble, could you look into enabling > getSourceFileName() testing in > > test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java > > > ?? It's currently on the "untested" list. > > thanks, > > dl > > On 4/21/20 1:12 PM, coleen.phillimore at oracle.com wrote: >> Summary: moved fields around and some constant fields into ConstantPool >> >> This is a simple change except that I moved some constant fields from >> InstanceKlass into the constant pool so they can be shared read-only >> in the CDS archive.? There are associated repercussions in SA and >> JVMCI, so please look at these changes. Also moved similarly sized >> fields together in the class so there's less likelihood of >> introducing gaps in future InstanceKlass changes. >> >> InstanceKlass is reduced from 544 to 520 bytes in a simple Hello >> World class. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8238048 >> >> Tested with tier1-6. >> >> Thanks, >> Coleen >> >> > From daniil.x.titov at oracle.com Wed Apr 22 17:48:11 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 22 Apr 2020 10:48:11 -0700 Subject: RFR: 8238561 serviceability/sa tests continue to run out of memory on Win* machines Message-ID: <8BFDF542-F950-472D-8EB4-DE32090C4A43@oracle.com> Please review the change [1] that ensures that VM and test options are forwarded to j*-tools when they are launched from serviceability/sa tests. In particular, it will ensure that passed to the tests maximum heap size settings ( -XX:MaxRAMPercentage) are also honored by j*-tools serviceability/sa tests launch. The tests that expect an empty output were corrected to ignore the product version printed in the error stream since in some tiers the tests are run with ' -showversion' VM option. Testing: Mach5 tests for tier1 - tier7 passed. [1] http://cr.openjdk.java.net/~dtitov/8238561/webrev.01 [2] https://bugs.openjdk.java.net/browse/JDK-8238561 Thank you, Daniil From serguei.spitsyn at oracle.com Wed Apr 22 18:22:57 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Apr 2020 11:22:57 -0700 Subject: RFR (L): 8241214: Test debugging of hidden classes using jdb Message-ID: <59dc7086-f276-df7a-f2d0-0831c7ab75f1@oracle.com> An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Wed Apr 22 18:42:31 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 22 Apr 2020 11:42:31 -0700 Subject: RFR(XS) 8243210: ClhsdbScanOops fails with NullPointerException in FileMapHeader.inCopiedVtableSpace In-Reply-To: References: <0f6811e4-f4c8-d87a-aedc-17350e899d34@oracle.com> Message-ID: Hi Chris, the change looks good to me, too. Thanks - Ioi On 4/21/20 6:35 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > It looks reasonable. > > Thanks, > Serguei > > > On 4/21/20 16:07, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8243210 >> http://cr.openjdk.java.net/~cjplummer/8243210/webrev.01/index.html >> >> Description is in the bug. Hopefully this is the last in a series of >> about 6 bugs being addressed that finally lets us get this test off >> the problem list for all platforms. >> >> thanks, >> >> Chris > From chris.plummer at oracle.com Wed Apr 22 19:23:17 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 22 Apr 2020 12:23:17 -0700 Subject: RFR(XS) 8243210: ClhsdbScanOops fails with NullPointerException in FileMapHeader.inCopiedVtableSpace In-Reply-To: References: <0f6811e4-f4c8-d87a-aedc-17350e899d34@oracle.com> Message-ID: Thanks Ioi and Serguei! Chris On 4/22/20 11:42 AM, Ioi Lam wrote: > Hi Chris, the change looks good to me, too. > > Thanks > - Ioi > > On 4/21/20 6:35 PM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> It looks reasonable. >> >> Thanks, >> Serguei >> >> >> On 4/21/20 16:07, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8243210 >>> http://cr.openjdk.java.net/~cjplummer/8243210/webrev.01/index.html >>> >>> Description is in the bug. Hopefully this is the last in a series of >>> about 6 bugs being addressed that finally lets us get this test off >>> the problem list for all platforms. >>> >>> thanks, >>> >>> Chris >> > From chris.plummer at oracle.com Wed Apr 22 19:54:43 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 22 Apr 2020 12:54:43 -0700 Subject: RFR: 8238561 serviceability/sa tests continue to run out of memory on Win* machines In-Reply-To: <8BFDF542-F950-472D-8EB4-DE32090C4A43@oracle.com> References: <8BFDF542-F950-472D-8EB4-DE32090C4A43@oracle.com> Message-ID: Hi Daniil, Thanks for cleaning this up. I think this should be fixed under JDK-8242009. JDK-8238561 involves more than just this one issue. Is there a reason why you didn't just change JDKToolLauncher to have an option or API to add the args? Why are you calling Utils.addTestJavaOpts() instead of Utils.getTestJavaOpts()? Is your change causing -Xshowversion to be passed? Do you know where it is coming from? thanks, Chris [1] https://bugs.openjdk.java.net/browse/JDK-8242009 On 4/22/20 10:48 AM, Daniil Titov wrote: > Please review the change [1] that ensures that VM and test options are forwarded to > j*-tools when they are launched from serviceability/sa tests. > > In particular, it will ensure that passed to the tests maximum heap size settings ( -XX:MaxRAMPercentage) > are also honored by j*-tools serviceability/sa tests launch. > > The tests that expect an empty output were corrected to ignore the product version printed > in the error stream since in some tiers the tests are run with ' -showversion' VM option. > > Testing: Mach5 tests for tier1 - tier7 passed. > > [1] http://cr.openjdk.java.net/~dtitov/8238561/webrev.01 > [2] https://bugs.openjdk.java.net/browse/JDK-8238561 > > Thank you, > Daniil > > From chris.plummer at oracle.com Wed Apr 22 20:02:34 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 22 Apr 2020 13:02:34 -0700 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: <9856771f-85a3-d490-1d19-5c0afd5f0438@oss.nttdata.com> References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> <056ba00d-4e1e-f48e-6d7e-10d026b0d2a6@oracle.com> <5a496dbd-abf9-0811-bb93-f35800396479@oss.nttdata.com> <9856771f-85a3-d490-1d19-5c0afd5f0438@oss.nttdata.com> Message-ID: <1d706206-6447-1b8a-9a1d-1055f6fa38a9@oracle.com> Hi Yasumasa, Yes, it looks like VMOps in SA can be removed. It's probably bit rotted code. My guess is at some point there was support, or were plans for supporting, the debugging of VMOps from within SA. Given that there are no references to the VMOps class, it looks like none of that support currently exists. thanks, Chris On 4/20/20 5:24 PM, Yasumasa Suenaga wrote: > Hi Rechard, > > Thank you for telling it to me. > > I grep'ed jdk.hotspot.agent with VMOps (it is just enum), it does not > seem to be used. > In addition, VMOps has not already synced to HotSpot. For example, > VM_HandshakeOneThread does not appear in VMOps. > (I wonder how do we use VMOps in SA) > > Thus I think we can (should) remove VMOps from jdk.hotspot.agent . > If other serviceability folks agree with it, I will file it to JBS. > > > Thanks, > > Yasumasa > > > On 2020/04/21 0:02, Reingruber, Richard wrote: >> Hi Yasumasa, >> >> I'm obviously late to this review. Still I wanted to let you know, >> that there's another file in the >> source tree that lists the VM operations in the VM (just found out >> about it myself): >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMOps.java >> >> Probably you should remove the VM operations from that file too. >> >> It seems to be part of the serviceability agent, which I hardly know. >> Would be good if somebody >> who is more familiar with it could let us know... >> >> Best regards, >> Richard. >> >> -----Original Message----- >> From: serviceability-dev >> On Behalf Of Yasumasa >> Suenaga >> Sent: Montag, 20. April 2020 02:33 >> To: serviceability-dev at openjdk.java.net >> Cc: yasuenag at gmail.com >> Subject: Re: RFR: 8242425: JVMTI monitor operations should use >> Thread-Local Handshakes >> >> Hi all, >> >> Could you review it? >> >> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >> ??? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ >> >> I need one more reviewer to push. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/17 5:13, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> Thank you for the update. >>> It looks good. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/10/20 04:30, Yasumasa Suenaga wrote: >>>> Hi Serguei, >>>> >>>> I use current_jt in this webrev. Could you review again? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ >>>> >>>> I tested this change with vmTestbase/nsk/jvmti, they are fine on my >>>> Linux x64. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/04/10 17:21, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa, >>>>> >>>>> Thank you for the update. >>>>> >>>>> Minor: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/src/hotspot/share/prims/jvmtiEnvBase.cpp.udiff.html >>>>> >>>>> >>>>> + err = get_locked_objects_in_frame(JavaThread::current(), >>>>> java_thread, jvf, owned_monitors_list, depth-1); . . . >>>>> >>>>> + JvmtiMonitorClosure jmc(java_thread, JavaThread::current(), >>>>> owned_monitors_list, this); >>>>> >>>>> You can use current_jt instead of JavaThread::current() above. >>>>> >>>>> There is also some test coverage in the >>>>> vmTestbase/nsk/jvmti/scenarios tests. >>>>> This one as well: >>>>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest >>>>> >>>>> Probably it is easier to run all vmTestbase/nsk/jvmti tests. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 4/10/20 01:05, Yasumasa Suenaga wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> Thanks for your comment! >>>>>> I uploaded new webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/ >>>>>> >>>>>> I ran following tests, and all of them were passed on my Linux x64. >>>>>> >>>>>> ??- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>>> ??- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>>> ??- vmTestbase/nsk/jdi >>>>>> ??- vmTestbase/nsk/jdwp >>>>>> ??- serviceability/jvmti/GetOwnedMonitorInfo >>>>>> ??- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>>> ??- serviceability/jdwp >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2020/04/10 14:50, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> It looks pretty good in general. >>>>>>> A couple of comments though. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> 650 JvmtiEnvBase::get_current_contended_monitor(JavaThread >>>>>>> *java_thread, jobject *monitor_ptr) { >>>>>>> 651 assert(!Thread::current()->is_VM_thread() && >>>>>>> 652 (Thread::current() == java_thread || >>>>>>> 653 Thread::current() == java_thread->active_handshaker()), >>>>>>> 654 "call by myself or at direct handshake"); >>>>>>> >>>>>>> ?? ... >>>>>>> >>>>>>> 685 JvmtiEnvBase::get_owned_monitors(JavaThread* java_thread, >>>>>>> ?? 686 GrowableArray >>>>>>> *owned_monitors_list) { >>>>>>> ?? 687?? jvmtiError err = JVMTI_ERROR_NONE; >>>>>>> 688 assert(!Thread::current()->is_VM_thread() && >>>>>>> 689 (Thread::current() == java_thread || >>>>>>> 690 Thread::current() == java_thread->active_handshaker()), >>>>>>> 691 "call by myself or at direct handshake"); >>>>>>> >>>>>>> I'd suggest to add this at the beginning: >>>>>>> ??? JavaThread *current_jt = JavaThread::current(); >>>>>>> >>>>>>> >>>>>>> 676 JavaThread *current_jt = reinterpret_cast>>>>>> *>(JavaThread::current()); >>>>>>> >>>>>>> There is not need in reinterpret_cast. Also, you >>>>>>> can use the current_jt defined above. >>>>>>> >>>>>>> Also, please, removed these two definitions as they became >>>>>>> unused with your fix: >>>>>>> ???? src/hotspot/share/runtime/vmOperations.hpp: >>>>>>> template(GGetCurrentContendedMonitoretOwnedMonitorInfo) \ >>>>>>> ???? src/hotspot/share/runtime/vmOperations.hpp: >>>>>>> template()??????????? \ >>>>>>> >>>>>>> The impacted JVMTI monitor functions are used in the JDWP agent >>>>>>> to support the JDI ThreadReference implementation. >>>>>>> To be safe the JDI & JDWP tests have to be run as well. It is >>>>>>> well covered by the tier-5. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 4/9/20 21:46, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review this change: >>>>>>>> >>>>>>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >>>>>>>> ?? webrev: >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/ >>>>>>>> >>>>>>>> We've discussed to use Thread-Local Handshake in some JVMTI >>>>>>>> functions [1]. >>>>>>>> This change is for monitor functions. It affects >>>>>>>> GetOwnedMonitorInfo(), GetOwnedMonitorStackDepthInfo(), >>>>>>>> GetCurrentContendedMonitor(). >>>>>>>> >>>>>>>> It passed tests on submit repo >>>>>>>> (mach5-one-ysuenaga-JDK-8242425-20200410-0228-10075639), and >>>>>>>> also I confirmed to pass following tests: >>>>>>>> >>>>>>>> ??- serviceability/jvmti/GetOwnedMonitorInfo >>>>>>>> ??- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>>>>> ??- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>>>>> ??- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html >>>>>>> >>>>> >>> From leonid.mesnik at oracle.com Wed Apr 22 20:06:53 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Wed, 22 Apr 2020 13:06:53 -0700 Subject: RFR (L): 8241214: Test debugging of hidden classes using jdb In-Reply-To: <59dc7086-f276-df7a-f2d0-0831c7ab75f1@oracle.com> References: <59dc7086-f276-df7a-f2d0-0831c7ab75f1@oracle.com> Message-ID: <01d3c5ec-2394-343b-b76d-70d775aff354@oracle.com> Looks good, Here are several comments, mostly about code style/compliance. No another review is needed if you want to fix them. http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-hidden-jdb.7/test/hotspot/jtreg/vmTestbase/nsk/jdb/hidden_class/hc001/hc001.java.html 36 interface HC_Interface { The name HC_Interface is not "CamelCase". 82 log = new PrintStream("Debuggee.log"); This PrintStream is not closed. Should not be a problem int this case, just good style. Leonid On 4/22/20 11:22 AM, serguei.spitsyn at oracle.com wrote: > Please, review a fix for the sub-task: > https://bugs.openjdk.java.net/browse/JDK-8241214 > > This fix has already been reviewed internally (in Vlahalla project) by > Mandy, Chris and Alex. > This RFR is to collect more comments (if there are any) before push. > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-hidden-jdb.7/ > > > Summary: > ? We want to be able to debug hidden classes with the debuggers. > ? One way to test the JDI/JDWP is by using the JDB, > ? so we want the JDB to support hidden classes. > ? The PatternReferenceTypeSpec::checkClassName is used to check > ? if the class is valid when a event requests is set in jdb. > ? Good example is to set a breakpoint which can be deferred. > ? The fix is to accept hidden class names as valid to be able > ? to debug hidden classes with the JDB. > ? New test is to provide basic coverage for JDB (amd JDI as well). > ? It verifies that the following JDB commands handle hidden classes > correctly: > ?? - class, classes > ?? - fields and methods > ?? - stop in, watch, unwatch > ?? - where, up and down > ?? - eval, print and dump for fields (both positive and negative checks) > > Testing: > ?Mach5 test run of the vmTestbase_nsk_jdb is in progress. > > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Apr 22 20:19:24 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Apr 2020 13:19:24 -0700 Subject: RFR (L): 8241214: Test debugging of hidden classes using jdb In-Reply-To: <01d3c5ec-2394-343b-b76d-70d775aff354@oracle.com> References: <59dc7086-f276-df7a-f2d0-0831c7ab75f1@oracle.com> <01d3c5ec-2394-343b-b76d-70d775aff354@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From hohensee at amazon.com Wed Apr 22 20:42:25 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 22 Apr 2020 20:42:25 +0000 Subject: RFR(L): 8215624: add parallel heap inspection support for jmap histo(G1)(Internet mail) Message-ID: For the interface, I'd use "parallel" instead of "parallelThreadNum". All the other options are lower case, and it's a lot easier to type "parallel". I took the liberty of updating the CSR. If you're ok with it, you might want to change variable names and such, plus of course JMap.usage. Thanks, Paul ?On 4/22/20, 2:29 AM, "serviceability-dev on behalf of linzang(??)" wrote: Dear Stefan, Thanks a lot! I agree with you to decouple the heap inspection code with GC's. I will start from your POC code, may discuss with you later. BRs, Lin On 2020/4/22, 5:14 PM, "Stefan Karlsson" wrote: Hi Lin, I took a look at this earlier and saw that the heap inspection code is strongly coupled with the CollectedHeap and G1CollectedHeap. I'd prefer if we'd abstract this away, so that the GCs only provide a "parallel object iteration" interface, and the heap inspection code is kept elsewhere. I started experimenting with doing that, but other higher-priority (to me) tasks have had to take precedence. I've uploaded my work-in-progress / proof-of-concept: https://cr.openjdk.java.net/~stefank/8215624/webrev.01.delta/ https://cr.openjdk.java.net/~stefank/8215624/webrev.01/ The current code doesn't handle the lifecycle (deletion) of the ParallelObjectIterators. There's also code left unimplemented in around CollectedHeap::run_task. However, I think this could work as a basis to pull out the heap inspection code out of the GCs. Thanks, StefanK On 2020-04-22 02:21, linzang(??) wrote: > Dear all, > May I ask you help to review? This RFR has been there for quite a while. > Thanks! > > BRs, > Lin > > > On 2020/3/16, 5:18 PM, "linzang(??)" wrote:> > >> Just update a new path, my preliminary measure show about 3.5x speedup of jmap histo on a nearly full 4GB G1 heap (8-core platform with parallel thread number set to 4). >> webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_02/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> BRs, >> Lin >> > On 2020/3/2, 9:56 PM, "linzang(??)" wrote: >> > >> > Dear all, >> > Let me try to ease the reviewing work by some explanation :P >> > The patch's target is to speed up jmap -histo for heap iteration, from my experience it is necessary for large heap investigation. E.g in bigData scenario I have tried to conduct jmap -histo against 180GB heap, it does take quite a while. >> > And if my understanding is corrent, even the jmap -histo without "live" option does heap inspection with heap lock acquired. so it is very likely to block mutator thread in allocation-sensitive scenario. I would say the faster the heap inspection does, the shorter the mutator be blocked. This is parallel iteration for jmap is necessary. >> > I think the parallel heap inspection should be applied to all kind of heap. However, consider the heap layout are different for GCs, much time is required to understand all kinds of the heap layout to make the whole change. IMO, It is not wise to have a huge patch for the whole solution at once, and it is even harder to review it. So I plan to implement it incrementally, the first patch (this one) is going to confirm the implemention detail of how jmap accept the new option, passes it to attachListener of the jvm process and then how to make the parallel inspection closure be generic enough to make it easy to extend to different heap layout. And also how to implement the heap inspection in specific gc's heap. This patch use G1's heap as the begining. >> > This patch actually do several things: >> > 1. Add an option "parallelThreadNum=" to jmap -histo, the default behavior is to set N to 0, means let's JVM decide how many threads to use for heap inspection. Set this option to 1 will disable parallel heap inspection. (more details in CSR: https://bugs.openjdk.java.net/browse/JDK-8239290) >> > 2. Make a change in how Jmap passing arguments, changes in http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html, originally it pass options as separate arguments to attachListener, this patch change to that all options be compose to a single string. So the arg_count_max in attachListener.hpp do not need to be changed, and hence avoid the compatibility issue, as disscussed at https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027334.html >> > 3. Add an abstract class ParHeapInspectTask in heapInspection.hpp / heapInspection.cpp, It's work(uint worker_id) method prepares the data structure (KlassInfoTable) need for every parallel worker thread, and then call do_object_iterate_parallel() which is heap specific implementation. I also added some machenism in KlassInfoTable to support parallel iteration, such as merge(). >> > 4. In specific heap (G1 in this patch), create a subclass of ParHeapInspectTask, implement the do_object_iterate_parallel() for parallel heap inspection. For G1, it simply invoke g1CollectedHeap's object_iterate_parallel(). >> > 5. Add related test. >> > 6. it may be easy to extend this patch for other kinds of heap by creating subclass of ParHeapInspectTask and implement the do_object_iterate_parallel(). >> > >> > Hope these info could help on code review and initate the discussion :-) >> > Thanks! >> > >> > BRs, >> > Lin >> > >On 2020/2/19, 9:40 AM, "linzang(??)" wrote:. >> > > >> > > Re-post this RFR with correct enhancement number to make it trackable. >> > > please ignore the previous wrong post. sorry for troubles. >> > > >> > > webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/ >> > > Hi bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > -------------- >> > > Lin >> > > >Hi Lin, > > > > > >> > > >Could you, please, re-post your RFR with the right enhancement number in >> > > >the message subject? >> > > >It will be more trackable this way. >> > > > >> > > >Thanks, >> > > >Serguei >> > > > >> > > > >> > > >On 2/17/20 10:29 PM, linzang(??) wrote: >> > > >> Dear David, >> > > >> Thanks a lot! >> > > >> I have updated the refined code to http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_01/. >> > > >> IMHO the parallel heap inspection can be extended to all kinds of heap as long as the heap layout can support parallel iteration. >> > > >> Maybe we can firstly use this webrev to discuss how to implement it, because I am not sure my current implementation is an appropriate way to communicate with collectedHeap, then we can extend the solution to other kinds of heap. >> > > >> >> > > >> Thanks, >> > > >> -------------- >> > > >> Lin >> > > >>> Hi Lin, >> > > >>> >> > > >>> Adding in hotspot-gc-dev as they need to see how this interacts with GC >> > > >>> worker threads, and whether it needs to be extended beyond G1. >> > > >>> >> > > >>> I happened to spot one nit when browsing: >> > > >>> >> > > >>> src/hotspot/share/gc/shared/collectedHeap.hpp >> > > >>> >> > > >>> + virtual bool run_par_heap_inspect_task(KlassInfoTable* cit, >> > > >>> + BoolObjectClosure* filter, >> > > >>> + size_t* missed_count, >> > > >>> + size_t thread_num) { >> > > >>> + return NULL; >> > > >>> >> > > >>> s/NULL/false/ >> > > >>> >> > > >>> Cheers, >> > > >>> David > > > > >>> >> > > >>> On 18/02/2020 2:15 pm, linzang(??) wrote: >> > > >>>> Dear All, >> > > >>>> May I ask your help to review the follow changes: >> > > >>>> webrev: >> > > >>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_00/ >> > > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > >>>> related CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > >>>> This patch enable parallel heap inspection of G1 for jmap histo. >> > > >>>> my simple test shown it can speed up 2x of jmap -histo with >> > > >>>> parallelThreadNum set to 2 for heap at ~500M on 4-core platform. >> > > >>>> >> > > >>>> ------------------------------------------------------------------------ >> > > >>>> BRs, >> > > >>>> Lin >> > > >> > >> > > > > > > From suenaga at oss.nttdata.com Thu Apr 23 00:00:46 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 23 Apr 2020 09:00:46 +0900 Subject: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes In-Reply-To: <1d706206-6447-1b8a-9a1d-1055f6fa38a9@oracle.com> References: <4752820b-21d7-789b-b0e8-8c96af05da6a@oss.nttdata.com> <590ca7e3-6fec-134a-dbc5-3e59d3c4183e@oracle.com> <7eab947b-ae31-b2be-659e-b023e2395e9b@oss.nttdata.com> <056ba00d-4e1e-f48e-6d7e-10d026b0d2a6@oracle.com> <5a496dbd-abf9-0811-bb93-f35800396479@oss.nttdata.com> <9856771f-85a3-d490-1d19-5c0afd5f0438@oss.nttdata.com> <1d706206-6447-1b8a-9a1d-1055f6fa38a9@oracle.com> Message-ID: <37f1ffab-0069-a040-4e78-72d355d4920c@oss.nttdata.com> Hi Chris, I filed it to JBS: https://bugs.openjdk.java.net/browse/JDK-8243450 I will send review request later. Thanks, Yasumasa On 2020/04/23 5:02, Chris Plummer wrote: > Hi Yasumasa, > > Yes, it looks like VMOps in SA can be removed. It's probably bit rotted code. My guess is at some point there was support, or were plans for supporting, the debugging of VMOps from within SA. Given that there are no references to the VMOps class, it looks like none of that support currently exists. > > thanks, > > Chris > > On 4/20/20 5:24 PM, Yasumasa Suenaga wrote: >> Hi Rechard, >> >> Thank you for telling it to me. >> >> I grep'ed jdk.hotspot.agent with VMOps (it is just enum), it does not seem to be used. >> In addition, VMOps has not already synced to HotSpot. For example, VM_HandshakeOneThread does not appear in VMOps. >> (I wonder how do we use VMOps in SA) >> >> Thus I think we can (should) remove VMOps from jdk.hotspot.agent . >> If other serviceability folks agree with it, I will file it to JBS. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/21 0:02, Reingruber, Richard wrote: >>> Hi Yasumasa, >>> >>> I'm obviously late to this review. Still I wanted to let you know, that there's another file in the >>> source tree that lists the VM operations in the VM (just found out about it myself): >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMOps.java >>> >>> Probably you should remove the VM operations from that file too. >>> >>> It seems to be part of the serviceability agent, which I hardly know. Would be good if somebody >>> who is more familiar with it could let us know... >>> >>> Best regards, >>> Richard. >>> >>> -----Original Message----- >>> From: serviceability-dev On Behalf Of Yasumasa Suenaga >>> Sent: Montag, 20. April 2020 02:33 >>> To: serviceability-dev at openjdk.java.net >>> Cc: yasuenag at gmail.com >>> Subject: Re: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes >>> >>> Hi all, >>> >>> Could you review it? >>> >>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >>> ??? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ >>> >>> I need one more reviewer to push. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/04/17 5:13, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> Thank you for the update. >>>> It looks good. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/10/20 04:30, Yasumasa Suenaga wrote: >>>>> Hi Serguei, >>>>> >>>>> I use current_jt in this webrev. Could you review again? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/ >>>>> >>>>> I tested this change with vmTestbase/nsk/jvmti, they are fine on my Linux x64. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2020/04/10 17:21, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Thank you for the update. >>>>>> >>>>>> Minor: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/src/hotspot/share/prims/jvmtiEnvBase.cpp.udiff.html >>>>>> >>>>>> + err = get_locked_objects_in_frame(JavaThread::current(), java_thread, jvf, owned_monitors_list, depth-1); . . . >>>>>> >>>>>> + JvmtiMonitorClosure jmc(java_thread, JavaThread::current(), owned_monitors_list, this); >>>>>> >>>>>> You can use current_jt instead of JavaThread::current() above. >>>>>> >>>>>> There is also some test coverage in the vmTestbase/nsk/jvmti/scenarios tests. >>>>>> This one as well: >>>>>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest >>>>>> Probably it is easier to run all vmTestbase/nsk/jvmti tests. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 4/10/20 01:05, Yasumasa Suenaga wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> Thanks for your comment! >>>>>>> I uploaded new webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/ >>>>>>> >>>>>>> I ran following tests, and all of them were passed on my Linux x64. >>>>>>> >>>>>>> ??- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>>>> ??- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>>>> ??- vmTestbase/nsk/jdi >>>>>>> ??- vmTestbase/nsk/jdwp >>>>>>> ??- serviceability/jvmti/GetOwnedMonitorInfo >>>>>>> ??- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>>>> ??- serviceability/jdwp >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2020/04/10 14:50, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> It looks pretty good in general. >>>>>>>> A couple of comments though. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html >>>>>>>> >>>>>>>> 650 JvmtiEnvBase::get_current_contended_monitor(JavaThread *java_thread, jobject *monitor_ptr) { >>>>>>>> 651 assert(!Thread::current()->is_VM_thread() && >>>>>>>> 652 (Thread::current() == java_thread || >>>>>>>> 653 Thread::current() == java_thread->active_handshaker()), >>>>>>>> 654 "call by myself or at direct handshake"); >>>>>>>> >>>>>>>> ?? ... >>>>>>>> >>>>>>>> 685 JvmtiEnvBase::get_owned_monitors(JavaThread* java_thread, >>>>>>>> ?? 686 GrowableArray *owned_monitors_list) { >>>>>>>> ?? 687?? jvmtiError err = JVMTI_ERROR_NONE; >>>>>>>> 688 assert(!Thread::current()->is_VM_thread() && >>>>>>>> 689 (Thread::current() == java_thread || >>>>>>>> 690 Thread::current() == java_thread->active_handshaker()), >>>>>>>> 691 "call by myself or at direct handshake"); >>>>>>>> >>>>>>>> I'd suggest to add this at the beginning: >>>>>>>> ??? JavaThread *current_jt = JavaThread::current(); >>>>>>>> >>>>>>>> >>>>>>>> 676 JavaThread *current_jt = reinterpret_cast(JavaThread::current()); >>>>>>>> >>>>>>>> There is not need in reinterpret_cast. Also, you can use the current_jt defined above. >>>>>>>> >>>>>>>> Also, please, removed these two definitions as they became unused with your fix: >>>>>>>> ???? src/hotspot/share/runtime/vmOperations.hpp: template(GGetCurrentContendedMonitoretOwnedMonitorInfo) \ >>>>>>>> ???? src/hotspot/share/runtime/vmOperations.hpp: template()??????????? \ >>>>>>>> >>>>>>>> The impacted JVMTI monitor functions are used in the JDWP agent to support the JDI ThreadReference implementation. >>>>>>>> To be safe the JDI & JDWP tests have to be run as well. It is well covered by the tier-5. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 4/9/20 21:46, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review this change: >>>>>>>>> >>>>>>>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8242425 >>>>>>>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/ >>>>>>>>> >>>>>>>>> We've discussed to use Thread-Local Handshake in some JVMTI functions [1]. >>>>>>>>> This change is for monitor functions. It affects GetOwnedMonitorInfo(), GetOwnedMonitorStackDepthInfo(), GetCurrentContendedMonitor(). >>>>>>>>> >>>>>>>>> It passed tests on submit repo (mach5-one-ysuenaga-JDK-8242425-20200410-0228-10075639), and also I confirmed to pass following tests: >>>>>>>>> >>>>>>>>> ??- serviceability/jvmti/GetOwnedMonitorInfo >>>>>>>>> ??- serviceability/jvmti/GetOwnedMonitorStackDepthInfo >>>>>>>>> ??- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor >>>>>>>>> ??- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html >>>>>>>> >>>>>> >>>> > > From dean.long at oracle.com Thu Apr 23 00:39:46 2020 From: dean.long at oracle.com (Dean Long) Date: Wed, 22 Apr 2020 17:39:46 -0700 Subject: RFR (M) Close alignment gaps in InstanceKlass In-Reply-To: References: <5a8317cb-dcdd-1fc5-7174-17304d75345a@oracle.com> Message-ID: <988a7d89-0304-edbd-b32a-e4b8428d8b8b@oracle.com> Can you compare the result to some string, like "Object.java"?? That seems to be what HotSpotResolvedObjectTypeTest.java is doing. Also, did getSourceFileName() return null for arrays before your change? dl On 4/22/20 8:18 AM, coleen.phillimore at oracle.com wrote: > > Hi Dean, Thank you for looking at the JVMCI changes and the suggestion > to add the test.? I did this and found a bug.? The new test is quite > limited because there's no good test to see if a source file name can > assertNotNull(type.getSourceFileName()), so I couldn't iterate through > the list of loaded classes like the other tests in that file. > > http://cr.openjdk.java.net/~coleenp/2020/8238048.02.incr/webrev/index.html > > > Thanks, > Coleen > > > On 4/21/20 9:51 PM, Dean Long wrote: >> Hi Coleen.? The JVMCI changes look OK.? It looks like there is a >> Graal unittest that covers getSourceFileName, but those tests don't >> always get run.? If it's not too much trouble, could you look into >> enabling getSourceFileName() testing in >> >> test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java >> >> >> ?? It's currently on the "untested" list. >> >> thanks, >> >> dl >> >> On 4/21/20 1:12 PM, coleen.phillimore at oracle.com wrote: >>> Summary: moved fields around and some constant fields into ConstantPool >>> >>> This is a simple change except that I moved some constant fields >>> from InstanceKlass into the constant pool so they can be shared >>> read-only in the CDS archive.? There are associated repercussions in >>> SA and JVMCI, so please look at these changes. Also moved similarly >>> sized fields together in the class so there's less likelihood of >>> introducing gaps in future InstanceKlass changes. >>> >>> InstanceKlass is reduced from 544 to 520 bytes in a simple Hello >>> World class. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8238048 >>> >>> Tested with tier1-6. >>> >>> Thanks, >>> Coleen >>> >>> >> > From dean.long at oracle.com Thu Apr 23 01:00:56 2020 From: dean.long at oracle.com (Dean Long) Date: Wed, 22 Apr 2020 18:00:56 -0700 Subject: RFR (M) Close alignment gaps in InstanceKlass In-Reply-To: <988a7d89-0304-edbd-b32a-e4b8428d8b8b@oracle.com> References: <5a8317cb-dcdd-1fc5-7174-17304d75345a@oracle.com> <988a7d89-0304-edbd-b32a-e4b8428d8b8b@oracle.com> Message-ID: <0d1f9056-e20e-a8bd-6e90-2012b4e37f20@oracle.com> It looks like calling the JVMCI getSourceFileName() on an array would have accessed random memory because it was expecting an InstanceKlass.? Instead of returning null we might want to throw an exception like in HotSpotResolvedPrimitiveType. dl On 4/22/20 5:39 PM, Dean Long wrote: > Can you compare the result to some string, like "Object.java"?? That > seems to be what HotSpotResolvedObjectTypeTest.java is doing. > Also, did getSourceFileName() return null for arrays before your change? > > dl > > On 4/22/20 8:18 AM, coleen.phillimore at oracle.com wrote: >> >> Hi Dean, Thank you for looking at the JVMCI changes and the >> suggestion to add the test.? I did this and found a bug.? The new >> test is quite limited because there's no good test to see if a source >> file name can assertNotNull(type.getSourceFileName()), so I couldn't >> iterate through the list of loaded classes like the other tests in >> that file. >> >> http://cr.openjdk.java.net/~coleenp/2020/8238048.02.incr/webrev/index.html >> >> >> Thanks, >> Coleen >> >> >> On 4/21/20 9:51 PM, Dean Long wrote: >>> Hi Coleen.? The JVMCI changes look OK. It looks like there is a >>> Graal unittest that covers getSourceFileName, but those tests don't >>> always get run.? If it's not too much trouble, could you look into >>> enabling getSourceFileName() testing in >>> >>> test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java >>> >>> >>> ?? It's currently on the "untested" list. >>> >>> thanks, >>> >>> dl >>> >>> On 4/21/20 1:12 PM, coleen.phillimore at oracle.com wrote: >>>> Summary: moved fields around and some constant fields into >>>> ConstantPool >>>> >>>> This is a simple change except that I moved some constant fields >>>> from InstanceKlass into the constant pool so they can be shared >>>> read-only in the CDS archive.? There are associated repercussions >>>> in SA and JVMCI, so please look at these changes. Also moved >>>> similarly sized fields together in the class so there's less >>>> likelihood of introducing gaps in future InstanceKlass changes. >>>> >>>> InstanceKlass is reduced from 544 to 520 bytes in a simple Hello >>>> World class. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8238048 >>>> >>>> Tested with tier1-6. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> >> > From suenaga at oss.nttdata.com Thu Apr 23 02:22:21 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 23 Apr 2020 11:22:21 +0900 Subject: RFR: 8243450: Reomve VMOps from jdk.hotspot.agent Message-ID: <0e076c48-e017-ae62-a839-cb0c945bee98@oss.nttdata.com> Hi all, Please review removing file from jdk.hotspot.agent: JBS: https://bugs.openjdk.java.net/browse/JDK-8243450 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8243450/webrev.00/ VMOps is enum class which lists all of VM Operation, but it has not been synced with HotSpot source. In addition, it is not used in src/ and test/. This change has passed tests on submit repo (mach5-one-ysuenaga-JDK-8243450-20200423-0039-10418768). Thanks, Yasumasa From coleen.phillimore at oracle.com Thu Apr 23 02:32:28 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 Apr 2020 22:32:28 -0400 Subject: RFR (M) Close alignment gaps in InstanceKlass In-Reply-To: <0d1f9056-e20e-a8bd-6e90-2012b4e37f20@oracle.com> References: <5a8317cb-dcdd-1fc5-7174-17304d75345a@oracle.com> <988a7d89-0304-edbd-b32a-e4b8428d8b8b@oracle.com> <0d1f9056-e20e-a8bd-6e90-2012b4e37f20@oracle.com> Message-ID: On 4/22/20 9:00 PM, Dean Long wrote: > It looks like calling the JVMCI getSourceFileName() on an array would > have accessed random memory because it was expecting an > InstanceKlass.? Instead of returning null we might want to throw an > exception like in HotSpotResolvedPrimitiveType. It was never called, except when I tried to call it on an array in the test.? It caused an assert in the hotspot code. How about this? Something else in that file throws JVMCIError with a similar message. ??? public String getSourceFileName() { ??????? if (isArray()) { ??????????? throw new JVMCIError("Cannot call getSourceFileName() on an array klass type: %s", this); ??????? } ??????? return getConstantPool().getSourceFileName(); ??? } > > dl > > On 4/22/20 5:39 PM, Dean Long wrote: >> Can you compare the result to some string, like "Object.java"?? That >> seems to be what HotSpotResolvedObjectTypeTest.java is doing. >> Also, did getSourceFileName() return null for arrays before your change? Fixed: ??? public void getSourceFileNameTest() { ??????? Class c = Object.class; ??????? ResolvedJavaType type = metaAccess.lookupJavaType(c); ??????? assertEquals(type.getSourceFileName(), "Object.java"); ??? } thanks, Coleen >> >> dl >> >> On 4/22/20 8:18 AM, coleen.phillimore at oracle.com wrote: >>> >>> Hi Dean, Thank you for looking at the JVMCI changes and the >>> suggestion to add the test.? I did this and found a bug.? The new >>> test is quite limited because there's no good test to see if a >>> source file name can assertNotNull(type.getSourceFileName()), so I >>> couldn't iterate through the list of loaded classes like the other >>> tests in that file. >>> >>> http://cr.openjdk.java.net/~coleenp/2020/8238048.02.incr/webrev/index.html >>> >>> >>> Thanks, >>> Coleen >>> >>> >>> On 4/21/20 9:51 PM, Dean Long wrote: >>>> Hi Coleen.? The JVMCI changes look OK. It looks like there is a >>>> Graal unittest that covers getSourceFileName, but those tests don't >>>> always get run.? If it's not too much trouble, could you look into >>>> enabling getSourceFileName() testing in >>>> >>>> test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java >>>> >>>> >>>> ?? It's currently on the "untested" list. >>>> >>>> thanks, >>>> >>>> dl >>>> >>>> On 4/21/20 1:12 PM, coleen.phillimore at oracle.com wrote: >>>>> Summary: moved fields around and some constant fields into >>>>> ConstantPool >>>>> >>>>> This is a simple change except that I moved some constant fields >>>>> from InstanceKlass into the constant pool so they can be shared >>>>> read-only in the CDS archive.? There are associated repercussions >>>>> in SA and JVMCI, so please look at these changes. Also moved >>>>> similarly sized fields together in the class so there's less >>>>> likelihood of introducing gaps in future InstanceKlass changes. >>>>> >>>>> InstanceKlass is reduced from 544 to 520 bytes in a simple Hello >>>>> World class. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8238048 >>>>> >>>>> Tested with tier1-6. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>> >>> >> > From chris.plummer at oracle.com Thu Apr 23 02:34:05 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 22 Apr 2020 19:34:05 -0700 Subject: RFR: 8243450: Reomve VMOps from jdk.hotspot.agent In-Reply-To: <0e076c48-e017-ae62-a839-cb0c945bee98@oss.nttdata.com> References: <0e076c48-e017-ae62-a839-cb0c945bee98@oss.nttdata.com> Message-ID: <752e0117-0257-7f18-5896-b3be4d97d410@oracle.com> Looks good. Chris On 4/22/20 7:22 PM, Yasumasa Suenaga wrote: > Hi all, > > Please review removing file from jdk.hotspot.agent: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8243450 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8243450/webrev.00/ > > VMOps is enum class which lists all of VM Operation, but it has not > been synced with HotSpot source. > In addition, it is not used in src/ and test/. > > This change has passed tests on submit repo > (mach5-one-ysuenaga-JDK-8243450-20200423-0039-10418768). > > > Thanks, > > Yasumasa From david.holmes at oracle.com Thu Apr 23 02:50:44 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Apr 2020 12:50:44 +1000 Subject: RFR: 8243450: Reomve VMOps from jdk.hotspot.agent In-Reply-To: <0e076c48-e017-ae62-a839-cb0c945bee98@oss.nttdata.com> References: <0e076c48-e017-ae62-a839-cb0c945bee98@oss.nttdata.com> Message-ID: Hi Yasumasa, On 23/04/2020 12:22 pm, Yasumasa Suenaga wrote: > Hi all, > > Please review removing file from jdk.hotspot.agent: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8243450 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8243450/webrev.00/ > > VMOps is enum class which lists all of VM Operation, but it has not been > synced with HotSpot source. > In addition, it is not used in src/ and test/. Strange. It was added by: https://bugs.openjdk.java.net/browse/JDK-8046282 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/74ab5b554535 but appears to be unused even then. So I guess it is okay to remove it. Thanks, David > This change has passed tests on submit repo > (mach5-one-ysuenaga-JDK-8243450-20200423-0039-10418768). > > > Thanks, > > Yasumasa From linzang at tencent.com Thu Apr 23 03:08:45 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Thu, 23 Apr 2020 03:08:45 +0000 Subject: RFR(L): 8215624: add parallel heap inspection support for jmap histo(G1)(Internet mail) In-Reply-To: References: Message-ID: <94C0D11E-F395-4FE4-9ECE-5ECC84B3AE1B@tencent.com> Thanks Paul! I agree with using "parallel", will make the update in next patch, Thanks for help update the CSR. BRs, Lin ?On 2020/4/23, 4:42 AM, "Hohensee, Paul" wrote: For the interface, I'd use "parallel" instead of "parallelThreadNum". All the other options are lower case, and it's a lot easier to type "parallel". I took the liberty of updating the CSR. If you're ok with it, you might want to change variable names and such, plus of course JMap.usage. Thanks, Paul On 4/22/20, 2:29 AM, "serviceability-dev on behalf of linzang(??)" wrote: Dear Stefan, Thanks a lot! I agree with you to decouple the heap inspection code with GC's. I will start from your POC code, may discuss with you later. BRs, Lin On 2020/4/22, 5:14 PM, "Stefan Karlsson" wrote: Hi Lin, I took a look at this earlier and saw that the heap inspection code is strongly coupled with the CollectedHeap and G1CollectedHeap. I'd prefer if we'd abstract this away, so that the GCs only provide a "parallel object iteration" interface, and the heap inspection code is kept elsewhere. I started experimenting with doing that, but other higher-priority (to me) tasks have had to take precedence. I've uploaded my work-in-progress / proof-of-concept: https://cr.openjdk.java.net/~stefank/8215624/webrev.01.delta/ https://cr.openjdk.java.net/~stefank/8215624/webrev.01/ The current code doesn't handle the lifecycle (deletion) of the ParallelObjectIterators. There's also code left unimplemented in around CollectedHeap::run_task. However, I think this could work as a basis to pull out the heap inspection code out of the GCs. Thanks, StefanK On 2020-04-22 02:21, linzang(??) wrote: > Dear all, > May I ask you help to review? This RFR has been there for quite a while. > Thanks! > > BRs, > Lin > > > On 2020/3/16, 5:18 PM, "linzang(??)" wrote:> > >> Just update a new path, my preliminary measure show about 3.5x speedup of jmap histo on a nearly full 4GB G1 heap (8-core platform with parallel thread number set to 4). >> webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_02/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> BRs, >> Lin >> > On 2020/3/2, 9:56 PM, "linzang(??)" wrote: >> > >> > Dear all, >> > Let me try to ease the reviewing work by some explanation :P >> > The patch's target is to speed up jmap -histo for heap iteration, from my experience it is necessary for large heap investigation. E.g in bigData scenario I have tried to conduct jmap -histo against 180GB heap, it does take quite a while. >> > And if my understanding is corrent, even the jmap -histo without "live" option does heap inspection with heap lock acquired. so it is very likely to block mutator thread in allocation-sensitive scenario. I would say the faster the heap inspection does, the shorter the mutator be blocked. This is parallel iteration for jmap is necessary. >> > I think the parallel heap inspection should be applied to all kind of heap. However, consider the heap layout are different for GCs, much time is required to understand all kinds of the heap layout to make the whole change. IMO, It is not wise to have a huge patch for the whole solution at once, and it is even harder to review it. So I plan to implement it incrementally, the first patch (this one) is going to confirm the implemention detail of how jmap accept the new option, passes it to attachListener of the jvm process and then how to make the parallel inspection closure be generic enough to make it easy to extend to different heap layout. And also how to implement the heap inspection in specific gc's heap. This patch use G1's heap as the begining. >> > This patch actually do several things: >> > 1. Add an option "parallelThreadNum=" to jmap -histo, the default behavior is to set N to 0, means let's JVM decide how many threads to use for heap inspection. Set this option to 1 will disable parallel heap inspection. (more details in CSR: https://bugs.openjdk.java.net/browse/JDK-8239290) >> > 2. Make a change in how Jmap passing arguments, changes in http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html, originally it pass options as separate arguments to attachListener, this patch change to that all options be compose to a single string. So the arg_count_max in attachListener.hpp do not need to be changed, and hence avoid the compatibility issue, as disscussed at https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027334.html >> > 3. Add an abstract class ParHeapInspectTask in heapInspection.hpp / heapInspection.cpp, It's work(uint worker_id) method prepares the data structure (KlassInfoTable) need for every parallel worker thread, and then call do_object_iterate_parallel() which is heap specific implementation. I also added some machenism in KlassInfoTable to support parallel iteration, such as merge(). >> > 4. In specific heap (G1 in this patch), create a subclass of ParHeapInspectTask, implement the do_object_iterate_parallel() for parallel heap inspection. For G1, it simply invoke g1CollectedHeap's object_iterate_parallel(). >> > 5. Add related test. >> > 6. it may be easy to extend this patch for other kinds of heap by creating subclass of ParHeapInspectTask and implement the do_object_iterate_parallel(). >> > >> > Hope these info could help on code review and initate the discussion :-) >> > Thanks! >> > >> > BRs, >> > Lin >> > >On 2020/2/19, 9:40 AM, "linzang(??)" wrote:. >> > > >> > > Re-post this RFR with correct enhancement number to make it trackable. >> > > please ignore the previous wrong post. sorry for troubles. >> > > >> > > webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/ >> > > Hi bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > -------------- >> > > Lin >> > > >Hi Lin, > > > > > >> > > >Could you, please, re-post your RFR with the right enhancement number in >> > > >the message subject? >> > > >It will be more trackable this way. >> > > > >> > > >Thanks, >> > > >Serguei >> > > > >> > > > >> > > >On 2/17/20 10:29 PM, linzang(??) wrote: >> > > >> Dear David, >> > > >> Thanks a lot! >> > > >> I have updated the refined code to http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_01/. >> > > >> IMHO the parallel heap inspection can be extended to all kinds of heap as long as the heap layout can support parallel iteration. >> > > >> Maybe we can firstly use this webrev to discuss how to implement it, because I am not sure my current implementation is an appropriate way to communicate with collectedHeap, then we can extend the solution to other kinds of heap. >> > > >> >> > > >> Thanks, >> > > >> -------------- >> > > >> Lin >> > > >>> Hi Lin, >> > > >>> >> > > >>> Adding in hotspot-gc-dev as they need to see how this interacts with GC >> > > >>> worker threads, and whether it needs to be extended beyond G1. >> > > >>> >> > > >>> I happened to spot one nit when browsing: >> > > >>> >> > > >>> src/hotspot/share/gc/shared/collectedHeap.hpp >> > > >>> >> > > >>> + virtual bool run_par_heap_inspect_task(KlassInfoTable* cit, >> > > >>> + BoolObjectClosure* filter, >> > > >>> + size_t* missed_count, >> > > >>> + size_t thread_num) { >> > > >>> + return NULL; >> > > >>> >> > > >>> s/NULL/false/ >> > > >>> >> > > >>> Cheers, >> > > >>> David > > > > >>> >> > > >>> On 18/02/2020 2:15 pm, linzang(??) wrote: >> > > >>>> Dear All, >> > > >>>> May I ask your help to review the follow changes: >> > > >>>> webrev: >> > > >>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_00/ >> > > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > >>>> related CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > >>>> This patch enable parallel heap inspection of G1 for jmap histo. >> > > >>>> my simple test shown it can speed up 2x of jmap -histo with >> > > >>>> parallelThreadNum set to 2 for heap at ~500M on 4-core platform. >> > > >>>> >> > > >>>> ------------------------------------------------------------------------ >> > > >>>> BRs, >> > > >>>> Lin >> > > >> > >> > > > > > > From suenaga at oss.nttdata.com Thu Apr 23 03:10:55 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 23 Apr 2020 12:10:55 +0900 Subject: RFR: 8243450: Reomve VMOps from jdk.hotspot.agent In-Reply-To: <0e076c48-e017-ae62-a839-cb0c945bee98@oss.nttdata.com> References: <0e076c48-e017-ae62-a839-cb0c945bee98@oss.nttdata.com> Message-ID: <9689aa8c-aab9-36dc-ec32-9ea0e9d1f23c@oss.nttdata.com> Thanks Chris and David for quick review! Yasumasa On 2020/04/23 11:22, Yasumasa Suenaga wrote: > Hi all, > > Please review removing file from jdk.hotspot.agent: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8243450 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8243450/webrev.00/ > > VMOps is enum class which lists all of VM Operation, but it has not been synced with HotSpot source. > In addition, it is not used in src/ and test/. > > This change has passed tests on submit repo (mach5-one-ysuenaga-JDK-8243450-20200423-0039-10418768). > > > Thanks, > > Yasumasa From daniil.x.titov at oracle.com Thu Apr 23 17:18:36 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 23 Apr 2020 10:18:36 -0700 Subject: RFR: 8238561 serviceability/sa tests continue to run out of memory on Win* machines In-Reply-To: References: <8BFDF542-F950-472D-8EB4-DE32090C4A43@oracle.com> Message-ID: Hi Chris, I will revoke this RFR and resubmit it under JDK-8242009 with the changes you suggested to use Utils.getTestJavaOpts() and make JDKToolLauncher to have an option to forward VM options. > Is your change causing -Xshowversion to be passed? Yes, the changes makes tests run with -Xshowversion to be passed. > Do you know where it is coming from? It is coming from task definitions for different tiers. Thank you, Daniil ?On 4/22/20, 12:54 PM, "Chris Plummer" wrote: Hi Daniil, Thanks for cleaning this up. I think this should be fixed under JDK-8242009. JDK-8238561 involves more than just this one issue. Is there a reason why you didn't just change JDKToolLauncher to have an option or API to add the args? Why are you calling Utils.addTestJavaOpts() instead of Utils.getTestJavaOpts()? Is your change causing -Xshowversion to be passed? Do you know where it is coming from? thanks, Chris [1] https://bugs.openjdk.java.net/browse/JDK-8242009 On 4/22/20 10:48 AM, Daniil Titov wrote: > Please review the change [1] that ensures that VM and test options are forwarded to > j*-tools when they are launched from serviceability/sa tests. > > In particular, it will ensure that passed to the tests maximum heap size settings ( -XX:MaxRAMPercentage) > are also honored by j*-tools serviceability/sa tests launch. > > The tests that expect an empty output were corrected to ignore the product version printed > in the error stream since in some tiers the tests are run with ' -showversion' VM option. > > Testing: Mach5 tests for tier1 - tier7 passed. > > [1] http://cr.openjdk.java.net/~dtitov/8238561/webrev.01 > [2] https://bugs.openjdk.java.net/browse/JDK-8238561 > > Thank you, > Daniil > > From daniil.x.titov at oracle.com Thu Apr 23 17:21:24 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 23 Apr 2020 10:21:24 -0700 Subject: RFR: 8238561 serviceability/sa tests continue to run out of memory on Win* machines In-Reply-To: References: <8BFDF542-F950-472D-8EB4-DE32090C4A43@oracle.com> Message-ID: <18DABA6E-F74D-44A1-97D2-BF7A3288EDDB@oracle.com> Correction... The option name is -showversion, not "-Xshowversion" Best regards, Daniil ?On 4/23/20, 10:18 AM, "Daniil Titov" wrote: Hi Chris, I will revoke this RFR and resubmit it under JDK-8242009 with the changes you suggested to use Utils.getTestJavaOpts() and make JDKToolLauncher to have an option to forward VM options. > Is your change causing -Xshowversion to be passed? Yes, the changes makes tests run with -Xshowversion to be passed. > Do you know where it is coming from? It is coming from task definitions for different tiers. Thank you, Daniil ?On 4/22/20, 12:54 PM, "Chris Plummer" wrote: Hi Daniil, Thanks for cleaning this up. I think this should be fixed under JDK-8242009. JDK-8238561 involves more than just this one issue. Is there a reason why you didn't just change JDKToolLauncher to have an option or API to add the args? Why are you calling Utils.addTestJavaOpts() instead of Utils.getTestJavaOpts()? Is your change causing -Xshowversion to be passed? Do you know where it is coming from? thanks, Chris [1] https://bugs.openjdk.java.net/browse/JDK-8242009 On 4/22/20 10:48 AM, Daniil Titov wrote: > Please review the change [1] that ensures that VM and test options are forwarded to > j*-tools when they are launched from serviceability/sa tests. > > In particular, it will ensure that passed to the tests maximum heap size settings ( -XX:MaxRAMPercentage) > are also honored by j*-tools serviceability/sa tests launch. > > The tests that expect an empty output were corrected to ignore the product version printed > in the error stream since in some tiers the tests are run with ' -showversion' VM option. > > Testing: Mach5 tests for tier1 - tier7 passed. > > [1] http://cr.openjdk.java.net/~dtitov/8238561/webrev.01 > [2] https://bugs.openjdk.java.net/browse/JDK-8238561 > > Thank you, > Daniil > > From coleen.phillimore at oracle.com Thu Apr 23 17:36:26 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 23 Apr 2020 13:36:26 -0400 Subject: RFR (M) Close alignment gaps in InstanceKlass In-Reply-To: References: Message-ID: Thanks, Ioi! Coleen On 4/23/20 12:43 PM, Ioi Lam wrote: > Hi Coleen, > > The changes look good to me. > > Thanks > - Ioi > > On 4/21/20 1:12 PM, coleen.phillimore at oracle.com wrote: >> Summary: moved fields around and some constant fields into ConstantPool >> >> This is a simple change except that I moved some constant fields from >> InstanceKlass into the constant pool so they can be shared read-only >> in the CDS archive.? There are associated repercussions in SA and >> JVMCI, so please look at these changes. Also moved similarly sized >> fields together in the class so there's less likelihood of >> introducing gaps in future InstanceKlass changes. >> >> InstanceKlass is reduced from 544 to 520 bytes in a simple Hello >> World class. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8238048 >> >> Tested with tier1-6. >> >> Thanks, >> Coleen >> >> > From chris.plummer at oracle.com Thu Apr 23 18:10:26 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 23 Apr 2020 11:10:26 -0700 Subject: RFR: 8238561 serviceability/sa tests continue to run out of memory on Win* machines In-Reply-To: References: <8BFDF542-F950-472D-8EB4-DE32090C4A43@oracle.com> Message-ID: On 4/23/20 10:18 AM, Daniil Titov wrote: > Hi Chris, > > I will revoke this RFR and resubmit it under JDK-8242009 > with the changes you suggested to use Utils.getTestJavaOpts() > and make JDKToolLauncher to have an option to forward VM options. > It could also be done with a new API such as JDKToolLauncher.addVMArgs(). That might be better than a new "create" API. thank,s Chris >> Is your change causing -Xshowversion to be passed? > Yes, the changes makes tests run with -Xshowversion to be passed. > >> Do you know where it is coming from? > It is coming from task definitions for different tiers. > > Thank you, > Daniil > > ?On 4/22/20, 12:54 PM, "Chris Plummer" wrote: > > Hi Daniil, > > Thanks for cleaning this up. I think this should be fixed under > JDK-8242009. JDK-8238561 involves more than just this one issue. > > Is there a reason why you didn't just change JDKToolLauncher to have an > option or API to add the args? > > Why are you calling Utils.addTestJavaOpts() instead of > Utils.getTestJavaOpts()? > > Is your change causing -Xshowversion to be passed? Do you know where it > is coming from? > > thanks, > > Chris > > [1] https://bugs.openjdk.java.net/browse/JDK-8242009 > > On 4/22/20 10:48 AM, Daniil Titov wrote: > > Please review the change [1] that ensures that VM and test options are forwarded to > > j*-tools when they are launched from serviceability/sa tests. > > > > In particular, it will ensure that passed to the tests maximum heap size settings ( -XX:MaxRAMPercentage) > > are also honored by j*-tools serviceability/sa tests launch. > > > > The tests that expect an empty output were corrected to ignore the product version printed > > in the error stream since in some tiers the tests are run with ' -showversion' VM option. > > > > Testing: Mach5 tests for tier1 - tier7 passed. > > > > [1] http://cr.openjdk.java.net/~dtitov/8238561/webrev.01 > > [2] https://bugs.openjdk.java.net/browse/JDK-8238561 > > > > Thank you, > > Daniil > > > > > > > From leonid.mesnik at oracle.com Thu Apr 23 18:23:21 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 23 Apr 2020 11:23:21 -0700 Subject: RFR: 8238561 serviceability/sa tests continue to run out of memory on Win* machines In-Reply-To: References: <8BFDF542-F950-472D-8EB4-DE32090C4A43@oracle.com> Message-ID: Hi Daniil Have you checked how longer tests are executed with adding java options to launchers (with Xcomp/Graal/ZGC)? If the overhead is not significant might be it make worth to add options by default? The idea is to add vm.opts to all processes and java.opts to tested only. But if you believe that adding java.opts to jdk tools helps to improve testing then it is better just to add it by default.? It helps to avoid similar failures in the future or with highly concurrent execution (when tens of jaotc are started for example). Leonid On 4/23/20 11:10 AM, Chris Plummer wrote: > On 4/23/20 10:18 AM, Daniil Titov wrote: >> Hi Chris, >> >> I will revoke this RFR and resubmit it under JDK-8242009 >> with the changes you suggested to use Utils.getTestJavaOpts() >> and make JDKToolLauncher to have an option to forward VM options. >> > It could also be done with a new API such as > JDKToolLauncher.addVMArgs(). That might be better than a new "create" > API. > > thank,s > > Chris >>> Is your change causing -Xshowversion to be passed? >> Yes, the changes makes? tests? run with -Xshowversion to be passed. >> >>> Do you know where it? is coming from? >> It is coming from task definitions for different tiers. >> >> Thank you, >> Daniil >> >> ?On 4/22/20, 12:54 PM, "Chris Plummer" wrote: >> >> ???? Hi Daniil, >> >> ???? Thanks for cleaning this up. I think this should be fixed under >> ???? JDK-8242009. JDK-8238561 involves more than just this one issue. >> >> ???? Is there a reason why you didn't just change JDKToolLauncher to >> have an >> ???? option or API to add the args? >> >> ???? Why are you calling Utils.addTestJavaOpts() instead of >> ???? Utils.getTestJavaOpts()? >> >> ???? Is your change causing -Xshowversion to be passed? Do you know >> where it >> ???? is coming from? >> >> ???? thanks, >> >> ???? Chris >> >> ???? [1] https://bugs.openjdk.java.net/browse/JDK-8242009 >> >> ???? On 4/22/20 10:48 AM, Daniil Titov wrote: >> ???? > Please review the change [1] that ensures that VM and test >> options are forwarded to >> ???? >?? j*-tools when they are launched from serviceability/sa tests. >> ???? > >> ???? > In particular, it will ensure that passed to the tests maximum >> heap size settings ( -XX:MaxRAMPercentage) >> ???? > are also honored by? j*-tools serviceability/sa? tests launch. >> ???? > >> ???? > The tests that expect an empty output? were corrected to >> ignore the product version printed >> ???? > in the error stream since in some? tiers the tests are run >> with ' -showversion' VM option. >> ???? > >> ???? > Testing:? Mach5 tests for tier1 - tier7 passed. >> ???? > >> ???? > [1] http://cr.openjdk.java.net/~dtitov/8238561/webrev.01 >> ???? > [2] https://bugs.openjdk.java.net/browse/JDK-8238561 >> ???? > >> ???? > Thank you, >> ???? > Daniil >> ???? > >> ???? > >> >> >> > > From dean.long at oracle.com Thu Apr 23 20:16:06 2020 From: dean.long at oracle.com (Dean Long) Date: Thu, 23 Apr 2020 13:16:06 -0700 Subject: RFR (M) Close alignment gaps in InstanceKlass In-Reply-To: References: <5a8317cb-dcdd-1fc5-7174-17304d75345a@oracle.com> <988a7d89-0304-edbd-b32a-e4b8428d8b8b@oracle.com> <0d1f9056-e20e-a8bd-6e90-2012b4e37f20@oracle.com> Message-ID: OK, thanks, looks good! dl On 4/22/20 7:32 PM, coleen.phillimore at oracle.com wrote: > > > On 4/22/20 9:00 PM, Dean Long wrote: >> It looks like calling the JVMCI getSourceFileName() on an array would >> have accessed random memory because it was expecting an >> InstanceKlass.? Instead of returning null we might want to throw an >> exception like in HotSpotResolvedPrimitiveType. > It was never called, except when I tried to call it on an array in the > test.? It caused an assert in the hotspot code. How about this? > Something else in that file throws JVMCIError with a similar message. > > ??? public String getSourceFileName() { > ??????? if (isArray()) { > ??????????? throw new JVMCIError("Cannot call getSourceFileName() on > an array klass type: %s", this); > ??????? } > ??????? return getConstantPool().getSourceFileName(); > ??? } > >> >> dl >> >> On 4/22/20 5:39 PM, Dean Long wrote: >>> Can you compare the result to some string, like "Object.java"?? That >>> seems to be what HotSpotResolvedObjectTypeTest.java is doing. >>> Also, did getSourceFileName() return null for arrays before your >>> change? > > Fixed: > ??? public void getSourceFileNameTest() { > ??????? Class c = Object.class; > ??????? ResolvedJavaType type = metaAccess.lookupJavaType(c); > ??????? assertEquals(type.getSourceFileName(), "Object.java"); > ??? } > > thanks, > Coleen > >>> >>> dl >>> >>> On 4/22/20 8:18 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> Hi Dean, Thank you for looking at the JVMCI changes and the >>>> suggestion to add the test.? I did this and found a bug. The new >>>> test is quite limited because there's no good test to see if a >>>> source file name can assertNotNull(type.getSourceFileName()), so I >>>> couldn't iterate through the list of loaded classes like the other >>>> tests in that file. >>>> >>>> http://cr.openjdk.java.net/~coleenp/2020/8238048.02.incr/webrev/index.html >>>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> On 4/21/20 9:51 PM, Dean Long wrote: >>>>> Hi Coleen.? The JVMCI changes look OK. It looks like there is a >>>>> Graal unittest that covers getSourceFileName, but those tests >>>>> don't always get run. If it's not too much trouble, could you look >>>>> into enabling getSourceFileName() testing in >>>>> >>>>> test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java >>>>> >>>>> >>>>> ?? It's currently on the "untested" list. >>>>> >>>>> thanks, >>>>> >>>>> dl >>>>> >>>>> On 4/21/20 1:12 PM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: moved fields around and some constant fields into >>>>>> ConstantPool >>>>>> >>>>>> This is a simple change except that I moved some constant fields >>>>>> from InstanceKlass into the constant pool so they can be shared >>>>>> read-only in the CDS archive.? There are associated repercussions >>>>>> in SA and JVMCI, so please look at these changes. Also moved >>>>>> similarly sized fields together in the class so there's less >>>>>> likelihood of introducing gaps in future InstanceKlass changes. >>>>>> >>>>>> InstanceKlass is reduced from 544 to 520 bytes in a simple Hello >>>>>> World class. >>>>>> >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8238048 >>>>>> >>>>>> Tested with tier1-6. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Thu Apr 23 20:27:29 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 23 Apr 2020 16:27:29 -0400 Subject: RFR (M) Close alignment gaps in InstanceKlass In-Reply-To: References: <5a8317cb-dcdd-1fc5-7174-17304d75345a@oracle.com> <988a7d89-0304-edbd-b32a-e4b8428d8b8b@oracle.com> <0d1f9056-e20e-a8bd-6e90-2012b4e37f20@oracle.com> Message-ID: Thanks, Dean! Coleen On 4/23/20 4:16 PM, Dean Long wrote: > OK, thanks, looks good! > > dl > > On 4/22/20 7:32 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 4/22/20 9:00 PM, Dean Long wrote: >>> It looks like calling the JVMCI getSourceFileName() on an array >>> would have accessed random memory because it was expecting an >>> InstanceKlass.? Instead of returning null we might want to throw an >>> exception like in HotSpotResolvedPrimitiveType. >> It was never called, except when I tried to call it on an array in >> the test.? It caused an assert in the hotspot code. How about this? >> Something else in that file throws JVMCIError with a similar message. >> >> ??? public String getSourceFileName() { >> ??????? if (isArray()) { >> ??????????? throw new JVMCIError("Cannot call getSourceFileName() on >> an array klass type: %s", this); >> ??????? } >> ??????? return getConstantPool().getSourceFileName(); >> ??? } >> >>> >>> dl >>> >>> On 4/22/20 5:39 PM, Dean Long wrote: >>>> Can you compare the result to some string, like "Object.java"?? >>>> That seems to be what HotSpotResolvedObjectTypeTest.java is doing. >>>> Also, did getSourceFileName() return null for arrays before your >>>> change? >> >> Fixed: >> ??? public void getSourceFileNameTest() { >> ??????? Class c = Object.class; >> ??????? ResolvedJavaType type = metaAccess.lookupJavaType(c); >> ??????? assertEquals(type.getSourceFileName(), "Object.java"); >> ??? } >> >> thanks, >> Coleen >> >>>> >>>> dl >>>> >>>> On 4/22/20 8:18 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> Hi Dean, Thank you for looking at the JVMCI changes and the >>>>> suggestion to add the test.? I did this and found a bug. The new >>>>> test is quite limited because there's no good test to see if a >>>>> source file name can assertNotNull(type.getSourceFileName()), so I >>>>> couldn't iterate through the list of loaded classes like the other >>>>> tests in that file. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2020/8238048.02.incr/webrev/index.html >>>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>> On 4/21/20 9:51 PM, Dean Long wrote: >>>>>> Hi Coleen.? The JVMCI changes look OK. It looks like there is a >>>>>> Graal unittest that covers getSourceFileName, but those tests >>>>>> don't always get run. If it's not too much trouble, could you >>>>>> look into enabling getSourceFileName() testing in >>>>>> >>>>>> test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java >>>>>> >>>>>> >>>>>> ?? It's currently on the "untested" list. >>>>>> >>>>>> thanks, >>>>>> >>>>>> dl >>>>>> >>>>>> On 4/21/20 1:12 PM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: moved fields around and some constant fields into >>>>>>> ConstantPool >>>>>>> >>>>>>> This is a simple change except that I moved some constant fields >>>>>>> from InstanceKlass into the constant pool so they can be shared >>>>>>> read-only in the CDS archive.? There are associated >>>>>>> repercussions in SA and JVMCI, so please look at these changes. >>>>>>> Also moved similarly sized fields together in the class so >>>>>>> there's less likelihood of introducing gaps in future >>>>>>> InstanceKlass changes. >>>>>>> >>>>>>> InstanceKlass is reduced from 544 to 520 bytes in a simple Hello >>>>>>> World class. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/2020/8238048.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8238048 >>>>>>> >>>>>>> Tested with tier1-6. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From chris.plummer at oracle.com Thu Apr 23 21:35:49 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 23 Apr 2020 14:35:49 -0700 Subject: RFR(S) 8231634: SA stack walking fails with "illegal bci" Message-ID: <8d9be633-2b65-a9b1-ddc1-ac89cf560474@oracle.com> Hello, Please help review the following: https://bugs.openjdk.java.net/browse/JDK-8231634 http://cr.openjdk.java.net/~cjplummer/8231634/webrev.00/index.html The fix is fairly simple: Don't use R13 as the BCP if it does not point into the methods actual bytecodes. Instead rely on the BCP value flushed to the frame. Details below are mostly there to help you understand the big picture of what is going on. First a bit a background on what the live_bcp field is in the X86Frame. BCP is "bytecode pointer". It points to the current bytecode being executed. I'm mostly just talking about interpreter frames here, but I think for compiled frames it points to the current native instruction being executed. For all but the current frame, frame->bcp reliably contains the BCP. For the current frame you normally need to look in a register for an up to date BCP. On x86_64 that's R13. When trying to find and create the current frame for a thread, eventually you end up in LinuxAMD64JavaThreadPDAccess.getCurrentFrameGuess(), which does: ????? // pass the value of R13 which contains the bcp for the top level frame ????? Address bcp = context.getRegisterAsAddress(AMD64ThreadContext.R13); ????? return new X86Frame(guesser.getSP(), guesser.getFP(), guesser.getPC(), null, bcp <-- live_bcp field); So in this case the X86Frame is constructed with R13 stored in the live_bcp field. For any frame other than the current frame, the live_bcp field will be NULL. And one other bit of clarification before moving on to the bug. You'll see BCX in code. For example, INTERPRETER_FRAME_BCX_OFFSET. BCX == BCP. I'm not sure why BCX was ever chosen. I was tempted to rename it to BCP, but it's been cloned to all the other SA CPU ports, so I think it's best to just leave it. Now on to the bug. Sometimes the interpreter uses R13 as a scratch register, so it does not always contain the BCP. This is why sometimes tests will see an "illegal bci" assert from SA. It's because r13 is currently not pointing to the BCP of the current frame, and thus can't be converted to a BCI. What this fix does take advantage of the fact that when r13 is used as a scratch register, it is first flushed to frame->bcp. So with this fix R13 is only used as the BCP if it points within the Method's bytecodes. If it does not, then SA will use the BCP flushed to frame->bcp. The reason we don't always used frame->bcp is because it is not kept up to date as the interpreter moves between bytecodes, but we know it is up to date if R13 is currently being used as a scratch register. So in other words, an invalid R13 implies that frame->bcp is up to date. And if you find yourself thinking "X86Frame.java supports is for both 32-bit and 64-bit x86, but R13 does not exists on 32-bit.", your right. A couple of years ago the concept of live_bcp was introduced to fix JDK-8214226 [1]. It only added support for fixing 64-bit and ignored 32-bit. So you'll never see live_bcp getting set for 32-bit, and thus JDK-8214226 is still broken on 32-bit, but it also means 32-bit is not impacted by the bug I'm fixing here. So the fix for JDK-8214226 is why you see R13 references in the X86Frame.java, but the code will still work for any platform that sets up live_bcd properly, even if it's not actually R13. ...and one more thing. 8214226 [1] actually introduced this "illegal bci" bug. However 8214226 [1] was only ever applied to LinuxAMD64. Never for BSD or Windows. This means two things: (1) the "illegal bci" bug never turned up on these platforms, and (2) 8214226 is still broken on these platform, meaning the bci returned by getInterpreterFrameBCI() is likely often stale, meaning stack traces will not show the proper line number for the current frame. It seems we don't have a test to catch this. I've filed 8243500 [2] to cover fixing 8214226 on BSD and Windows. [1] https://bugs.openjdk.java.net/browse/JDK-8214226 [2] https://bugs.openjdk.java.net/browse/JDK-8243500 thanks, Chris From serguei.spitsyn at oracle.com Fri Apr 24 04:01:27 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Apr 2020 21:01:27 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Apr 24 07:44:35 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 24 Apr 2020 00:44:35 -0700 Subject: RFR(M) 8243500: SA: Incorrect BCI and Line Number with jstack if the top frame is in the interpreter (BSD and Windows) Message-ID: <02c3237c-8890-7c10-530b-5a6b52684126@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8243500 http://cr.openjdk.java.net/~cjplummer/8243500/webrev.00/index.html A couple years ago JDK-8214226 fixed an issue on Linux-x64 with SA stack dumps not properly displaying the correct line number for the topmost frame if it was interpreted. The issue was that SA was always relying on frame->bcp when in fact the BCP is kept in R13, and only flushed to frame->bcp when needed as a scratch register. So this means that SA was in most cases grabbing a stale value from frame->bcp. The fix for JDK-8214226 was mostly made in X86Frame.java to support using the BCP register for the topmost frame instead using frame->bcp. This fix actually had a bug in it that was causing the "illegal bci" failures we've been seeing. There is already a separate webrev and RFR out for that: https://bugs.openjdk.java.net/browse/JDK-8231634 http://cr.openjdk.java.net/~cjplummer/8231634/webrev.00/index.html What this RFR addresses is the fact that part of the fix for JDK-8214226 was in LinuxAMD64JavaThreadPDAccess.java, but the same changes were never made to WindowsAMD64JavaThreadPDAccess.java or BsdAMD64JavaThreadPDAccess.java. This fix addresses those two ports. Here's the CR and changeset for reference: https://bugs.openjdk.java.net/browse/JDK-8214226 http://hg.openjdk.java.net/jdk/jdk/rev/9a73a4e4011f The changes for the fix are pretty trivial. The more complicated part is the test I added that will reproduce the issue 100% of the time on platforms where SA does not properly check the BCP register. For this reason I've used @requires to limit running this test on just those platforms I know have the support in place. The test has pretty good comments on how it works, so I won't go into details here. thanks, Chris From richard.reingruber at sap.com Fri Apr 24 08:18:31 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 24 Apr 2020 08:18:31 +0000 Subject: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant In-Reply-To: References: <3c59b9f9-ec38-18c9-8f24-e1186a08a04a@oracle.com> <410eed04-e2ef-0f4f-1c56-19e6734a10f6@oracle.com> Message-ID: Hi Patricio, Vladimir, and Serguei, now that direct handshakes are available, I've updated the patch to make use of them. In addition I have done some clean-up changes I missed in the first webrev. Finally I have implemented the workaround suggested by Patricio to avoid nesting the handshake into the vm operation VM_SetFramePop [1] Kindly review again: Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode can be replaced with a direct handshake: JBS: https://bugs.openjdk.java.net/browse/JDK-8238585 Testing: * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737 Thanks, Richard. [1] An assertion in Handshake::execute_direct() fails, if called be VMThread, because it is no JavaThread. -----Original Message----- From: hotspot-dev On Behalf Of Reingruber, Richard Sent: Freitag, 14. Februar 2020 19:47 To: Patricio Chilano ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant Hi Patricio, > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a > > handshake cannot be nested in a vm operation. Maybe it should be asserted in the > > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? > > > > > Alternatively I think you could do something similar to what we do in > > > Deoptimization::deoptimize_all_marked(): > > > > > > EnterInterpOnlyModeClosure hs; > > > if (SafepointSynchronize::is_at_safepoint()) { > > > hs.do_thread(state->get_thread()); > > > } else { > > > Handshake::execute(&hs, state->get_thread()); > > > } > > > (you could pass ?EnterInterpOnlyModeClosure? directly to the > > > HandshakeClosure() constructor) > > > > Maybe this could be used also in the Handshake::execute() methods as general solution? > Right, we could also do that. Avoiding to clear the polling page in > HandshakeState::clear_handshake() should be enough to fix this issue and > execute a handshake inside a safepoint, but adding that "if" statement > in Hanshake::execute() sounds good to avoid all the extra code that we > go through when executing a handshake. I filed 8239084 to make that change. Thanks for taking care of this and creating the RFE. > > > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is > > > always called in a nested operation or just sometimes. > > > > At least one execution path without vm operation exists: > > > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void > > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong > > JvmtiEventControllerPrivate::recompute_enabled() : void > > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) > > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void > > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError > > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError > > > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a > > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further > > encouraged to do it with a handshake :) > Ah! I think you can still do it with a handshake with the > Deoptimization::deoptimize_all_marked() like solution. I can change the > if-else statement with just the Handshake::execute() call in 8239084. > But up to you. : ) Well, I think that's enough encouragement :) I'll wait for 8239084 and try then again. (no urgency and all) Thanks, Richard. -----Original Message----- From: Patricio Chilano Sent: Freitag, 14. Februar 2020 15:54 To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant Hi Richard, On 2/14/20 9:58 AM, Reingruber, Richard wrote: > Hi Patricio, > > thanks for having a look. > > > I?m only commenting on the handshake changes. > > I see that operation VM_EnterInterpOnlyMode can be called inside > > operation VM_SetFramePop which also allows nested operations. Here is a > > comment in VM_SetFramePop definition: > > > > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is > > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. > > > > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we > > could have a handshake inside a safepoint operation. The issue I see > > there is that at the end of the handshake the polling page of the target > > thread could be disarmed. So if the target thread happens to be in a > > blocked state just transiently and wakes up then it will not stop for > > the ongoing safepoint. Maybe I can file an RFE to assert that the > > polling page is armed at the beginning of disarm_safepoint(). > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a > handshake cannot be nested in a vm operation. Maybe it should be asserted in the > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? > > > Alternatively I think you could do something similar to what we do in > > Deoptimization::deoptimize_all_marked(): > > > > EnterInterpOnlyModeClosure hs; > > if (SafepointSynchronize::is_at_safepoint()) { > > hs.do_thread(state->get_thread()); > > } else { > > Handshake::execute(&hs, state->get_thread()); > > } > > (you could pass ?EnterInterpOnlyModeClosure? directly to the > > HandshakeClosure() constructor) > > Maybe this could be used also in the Handshake::execute() methods as general solution? Right, we could also do that. Avoiding to clear the polling page in HandshakeState::clear_handshake() should be enough to fix this issue and execute a handshake inside a safepoint, but adding that "if" statement in Hanshake::execute() sounds good to avoid all the extra code that we go through when executing a handshake. I filed 8239084 to make that change. > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is > > always called in a nested operation or just sometimes. > > At least one execution path without vm operation exists: > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong > JvmtiEventControllerPrivate::recompute_enabled() : void > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further > encouraged to do it with a handshake :) Ah! I think you can still do it with a handshake with the Deoptimization::deoptimize_all_marked() like solution. I can change the if-else statement with just the Handshake::execute() call in 8239084. But up to you.? : ) Thanks, Patricio > Thanks again, > Richard. > > -----Original Message----- > From: Patricio Chilano > Sent: Donnerstag, 13. Februar 2020 18:47 > To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Richard, > > I?m only commenting on the handshake changes. > I see that operation VM_EnterInterpOnlyMode can be called inside > operation VM_SetFramePop which also allows nested operations. Here is a > comment in VM_SetFramePop definition: > > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. > > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we > could have a handshake inside a safepoint operation. The issue I see > there is that at the end of the handshake the polling page of the target > thread could be disarmed. So if the target thread happens to be in a > blocked state just transiently and wakes up then it will not stop for > the ongoing safepoint. Maybe I can file an RFE to assert that the > polling page is armed at the beginning of disarm_safepoint(). > > I think one option could be to remove > SafepointMechanism::disarm_if_needed() in > HandshakeState::clear_handshake() and let each JavaThread disarm itself > for the handshake case. > > Alternatively I think you could do something similar to what we do in > Deoptimization::deoptimize_all_marked(): > > ? EnterInterpOnlyModeClosure hs; > ? if (SafepointSynchronize::is_at_safepoint()) { > ??? hs.do_thread(state->get_thread()); > ? } else { > ??? Handshake::execute(&hs, state->get_thread()); > ? } > (you could pass ?EnterInterpOnlyModeClosure? directly to the > HandshakeClosure() constructor) > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is > always called in a nested operation or just sometimes. > > Thanks, > Patricio > > On 2/12/20 7:23 AM, Reingruber, Richard wrote: >> // Repost including hotspot runtime and gc lists. >> // Dean Long suggested to do so, because the enhancement replaces a vm operation >> // with a handshake. >> // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html >> >> Hi, >> >> could I please get reviews for this small enhancement in hotspot's jvmti implementation: >> >> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >> >> The change avoids making all compiled methods on stack not_entrant when switching a java thread to >> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. >> >> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. >> >> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >> >> Thanks, Richard. >> >> See also my question if anyone knows a reason for making the compiled methods not_entrant: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html From suenaga at oss.nttdata.com Fri Apr 24 11:34:22 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 24 Apr 2020 20:34:22 +0900 Subject: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant In-Reply-To: References: <3c59b9f9-ec38-18c9-8f24-e1186a08a04a@oracle.com> <410eed04-e2ef-0f4f-1c56-19e6734a10f6@oracle.com> Message-ID: Hi Richard, I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. Does it help you? I think it gives you to remove workaround. (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) Thanks, Yasumasa On 2020/04/24 17:18, Reingruber, Richard wrote: > Hi Patricio, Vladimir, and Serguei, > > now that direct handshakes are available, I've updated the patch to make use of them. > > In addition I have done some clean-up changes I missed in the first webrev. > > Finally I have implemented the workaround suggested by Patricio to avoid nesting the handshake > into the vm operation VM_SetFramePop [1] > > Kindly review again: > > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ > Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ > > I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode can be replaced with a > direct handshake: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8238585 > > Testing: > > * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. > > * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737 > > Thanks, > Richard. > > [1] An assertion in Handshake::execute_direct() fails, if called be VMThread, because it is no JavaThread. > > -----Original Message----- > From: hotspot-dev On Behalf Of Reingruber, Richard > Sent: Freitag, 14. Februar 2020 19:47 > To: Patricio Chilano ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Patricio, > > > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a > > > handshake cannot be nested in a vm operation. Maybe it should be asserted in the > > > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? > > > > > > > Alternatively I think you could do something similar to what we do in > > > > Deoptimization::deoptimize_all_marked(): > > > > > > > > EnterInterpOnlyModeClosure hs; > > > > if (SafepointSynchronize::is_at_safepoint()) { > > > > hs.do_thread(state->get_thread()); > > > > } else { > > > > Handshake::execute(&hs, state->get_thread()); > > > > } > > > > (you could pass ?EnterInterpOnlyModeClosure? directly to the > > > > HandshakeClosure() constructor) > > > > > > Maybe this could be used also in the Handshake::execute() methods as general solution? > > Right, we could also do that. Avoiding to clear the polling page in > > HandshakeState::clear_handshake() should be enough to fix this issue and > > execute a handshake inside a safepoint, but adding that "if" statement > > in Hanshake::execute() sounds good to avoid all the extra code that we > > go through when executing a handshake. I filed 8239084 to make that change. > > Thanks for taking care of this and creating the RFE. > > > > > > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is > > > > always called in a nested operation or just sometimes. > > > > > > At least one execution path without vm operation exists: > > > > > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void > > > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong > > > JvmtiEventControllerPrivate::recompute_enabled() : void > > > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) > > > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void > > > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError > > > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError > > > > > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a > > > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further > > > encouraged to do it with a handshake :) > > Ah! I think you can still do it with a handshake with the > > Deoptimization::deoptimize_all_marked() like solution. I can change the > > if-else statement with just the Handshake::execute() call in 8239084. > > But up to you. : ) > > Well, I think that's enough encouragement :) > I'll wait for 8239084 and try then again. > (no urgency and all) > > Thanks, > Richard. > > -----Original Message----- > From: Patricio Chilano > Sent: Freitag, 14. Februar 2020 15:54 > To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Richard, > > On 2/14/20 9:58 AM, Reingruber, Richard wrote: >> Hi Patricio, >> >> thanks for having a look. >> >> > I?m only commenting on the handshake changes. >> > I see that operation VM_EnterInterpOnlyMode can be called inside >> > operation VM_SetFramePop which also allows nested operations. Here is a >> > comment in VM_SetFramePop definition: >> > >> > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >> > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >> > >> > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >> > could have a handshake inside a safepoint operation. The issue I see >> > there is that at the end of the handshake the polling page of the target >> > thread could be disarmed. So if the target thread happens to be in a >> > blocked state just transiently and wakes up then it will not stop for >> > the ongoing safepoint. Maybe I can file an RFE to assert that the >> > polling page is armed at the beginning of disarm_safepoint(). >> >> I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >> handshake cannot be nested in a vm operation. Maybe it should be asserted in the >> Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >> >> > Alternatively I think you could do something similar to what we do in >> > Deoptimization::deoptimize_all_marked(): >> > >> > EnterInterpOnlyModeClosure hs; >> > if (SafepointSynchronize::is_at_safepoint()) { >> > hs.do_thread(state->get_thread()); >> > } else { >> > Handshake::execute(&hs, state->get_thread()); >> > } >> > (you could pass ?EnterInterpOnlyModeClosure? directly to the >> > HandshakeClosure() constructor) >> >> Maybe this could be used also in the Handshake::execute() methods as general solution? > Right, we could also do that. Avoiding to clear the polling page in > HandshakeState::clear_handshake() should be enough to fix this issue and > execute a handshake inside a safepoint, but adding that "if" statement > in Hanshake::execute() sounds good to avoid all the extra code that we > go through when executing a handshake. I filed 8239084 to make that change. > >> > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >> > always called in a nested operation or just sometimes. >> >> At least one execution path without vm operation exists: >> >> JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >> JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >> JvmtiEventControllerPrivate::recompute_enabled() : void >> JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >> JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >> JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >> jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >> >> I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >> handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >> encouraged to do it with a handshake :) > Ah! I think you can still do it with a handshake with the > Deoptimization::deoptimize_all_marked() like solution. I can change the > if-else statement with just the Handshake::execute() call in 8239084. > But up to you.? : ) > > Thanks, > Patricio >> Thanks again, >> Richard. >> >> -----Original Message----- >> From: Patricio Chilano >> Sent: Donnerstag, 13. Februar 2020 18:47 >> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Richard, >> >> I?m only commenting on the handshake changes. >> I see that operation VM_EnterInterpOnlyMode can be called inside >> operation VM_SetFramePop which also allows nested operations. Here is a >> comment in VM_SetFramePop definition: >> >> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >> >> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >> could have a handshake inside a safepoint operation. The issue I see >> there is that at the end of the handshake the polling page of the target >> thread could be disarmed. So if the target thread happens to be in a >> blocked state just transiently and wakes up then it will not stop for >> the ongoing safepoint. Maybe I can file an RFE to assert that the >> polling page is armed at the beginning of disarm_safepoint(). >> >> I think one option could be to remove >> SafepointMechanism::disarm_if_needed() in >> HandshakeState::clear_handshake() and let each JavaThread disarm itself >> for the handshake case. >> >> Alternatively I think you could do something similar to what we do in >> Deoptimization::deoptimize_all_marked(): >> >> ? EnterInterpOnlyModeClosure hs; >> ? if (SafepointSynchronize::is_at_safepoint()) { >> ??? hs.do_thread(state->get_thread()); >> ? } else { >> ??? Handshake::execute(&hs, state->get_thread()); >> ? } >> (you could pass ?EnterInterpOnlyModeClosure? directly to the >> HandshakeClosure() constructor) >> >> I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >> always called in a nested operation or just sometimes. >> >> Thanks, >> Patricio >> >> On 2/12/20 7:23 AM, Reingruber, Richard wrote: >>> // Repost including hotspot runtime and gc lists. >>> // Dean Long suggested to do so, because the enhancement replaces a vm operation >>> // with a handshake. >>> // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html >>> >>> Hi, >>> >>> could I please get reviews for this small enhancement in hotspot's jvmti implementation: >>> >>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >>> >>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to >>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. >>> >>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. >>> >>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>> >>> Thanks, Richard. >>> >>> See also my question if anyone knows a reason for making the compiled methods not_entrant: >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html > From richard.reingruber at sap.com Fri Apr 24 14:44:29 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 24 Apr 2020 14:44:29 +0000 Subject: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant In-Reply-To: References: <3c59b9f9-ec38-18c9-8f24-e1186a08a04a@oracle.com> <410eed04-e2ef-0f4f-1c56-19e6734a10f6@oracle.com> Message-ID: Hi Yasumasa, > I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. > Does it help you? I think it gives you to remove workaround. I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. Also my first impression was that it won't be that easy from a synchronization point of view to replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear to me, how this has to be handled. So it appears to me that it would be easier to push JDK-8242427 after this (JDK-8238585). > (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) Would be interesting to see how you handled the issues above :) Thanks, Richard. [1] See question in comment https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030 -----Original Message----- From: Yasumasa Suenaga Sent: Freitag, 24. April 2020 13:34 To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant Hi Richard, I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. Does it help you? I think it gives you to remove workaround. (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) Thanks, Yasumasa On 2020/04/24 17:18, Reingruber, Richard wrote: > Hi Patricio, Vladimir, and Serguei, > > now that direct handshakes are available, I've updated the patch to make use of them. > > In addition I have done some clean-up changes I missed in the first webrev. > > Finally I have implemented the workaround suggested by Patricio to avoid nesting the handshake > into the vm operation VM_SetFramePop [1] > > Kindly review again: > > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ > Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ > > I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode can be replaced with a > direct handshake: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8238585 > > Testing: > > * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. > > * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737 > > Thanks, > Richard. > > [1] An assertion in Handshake::execute_direct() fails, if called be VMThread, because it is no JavaThread. > > -----Original Message----- > From: hotspot-dev On Behalf Of Reingruber, Richard > Sent: Freitag, 14. Februar 2020 19:47 > To: Patricio Chilano ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Patricio, > > > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a > > > handshake cannot be nested in a vm operation. Maybe it should be asserted in the > > > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? > > > > > > > Alternatively I think you could do something similar to what we do in > > > > Deoptimization::deoptimize_all_marked(): > > > > > > > > EnterInterpOnlyModeClosure hs; > > > > if (SafepointSynchronize::is_at_safepoint()) { > > > > hs.do_thread(state->get_thread()); > > > > } else { > > > > Handshake::execute(&hs, state->get_thread()); > > > > } > > > > (you could pass ?EnterInterpOnlyModeClosure? directly to the > > > > HandshakeClosure() constructor) > > > > > > Maybe this could be used also in the Handshake::execute() methods as general solution? > > Right, we could also do that. Avoiding to clear the polling page in > > HandshakeState::clear_handshake() should be enough to fix this issue and > > execute a handshake inside a safepoint, but adding that "if" statement > > in Hanshake::execute() sounds good to avoid all the extra code that we > > go through when executing a handshake. I filed 8239084 to make that change. > > Thanks for taking care of this and creating the RFE. > > > > > > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is > > > > always called in a nested operation or just sometimes. > > > > > > At least one execution path without vm operation exists: > > > > > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void > > > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong > > > JvmtiEventControllerPrivate::recompute_enabled() : void > > > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) > > > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void > > > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError > > > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError > > > > > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a > > > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further > > > encouraged to do it with a handshake :) > > Ah! I think you can still do it with a handshake with the > > Deoptimization::deoptimize_all_marked() like solution. I can change the > > if-else statement with just the Handshake::execute() call in 8239084. > > But up to you. : ) > > Well, I think that's enough encouragement :) > I'll wait for 8239084 and try then again. > (no urgency and all) > > Thanks, > Richard. > > -----Original Message----- > From: Patricio Chilano > Sent: Freitag, 14. Februar 2020 15:54 > To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Richard, > > On 2/14/20 9:58 AM, Reingruber, Richard wrote: >> Hi Patricio, >> >> thanks for having a look. >> >> > I?m only commenting on the handshake changes. >> > I see that operation VM_EnterInterpOnlyMode can be called inside >> > operation VM_SetFramePop which also allows nested operations. Here is a >> > comment in VM_SetFramePop definition: >> > >> > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >> > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >> > >> > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >> > could have a handshake inside a safepoint operation. The issue I see >> > there is that at the end of the handshake the polling page of the target >> > thread could be disarmed. So if the target thread happens to be in a >> > blocked state just transiently and wakes up then it will not stop for >> > the ongoing safepoint. Maybe I can file an RFE to assert that the >> > polling page is armed at the beginning of disarm_safepoint(). >> >> I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >> handshake cannot be nested in a vm operation. Maybe it should be asserted in the >> Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >> >> > Alternatively I think you could do something similar to what we do in >> > Deoptimization::deoptimize_all_marked(): >> > >> > EnterInterpOnlyModeClosure hs; >> > if (SafepointSynchronize::is_at_safepoint()) { >> > hs.do_thread(state->get_thread()); >> > } else { >> > Handshake::execute(&hs, state->get_thread()); >> > } >> > (you could pass ?EnterInterpOnlyModeClosure? directly to the >> > HandshakeClosure() constructor) >> >> Maybe this could be used also in the Handshake::execute() methods as general solution? > Right, we could also do that. Avoiding to clear the polling page in > HandshakeState::clear_handshake() should be enough to fix this issue and > execute a handshake inside a safepoint, but adding that "if" statement > in Hanshake::execute() sounds good to avoid all the extra code that we > go through when executing a handshake. I filed 8239084 to make that change. > >> > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >> > always called in a nested operation or just sometimes. >> >> At least one execution path without vm operation exists: >> >> JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >> JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >> JvmtiEventControllerPrivate::recompute_enabled() : void >> JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >> JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >> JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >> jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >> >> I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >> handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >> encouraged to do it with a handshake :) > Ah! I think you can still do it with a handshake with the > Deoptimization::deoptimize_all_marked() like solution. I can change the > if-else statement with just the Handshake::execute() call in 8239084. > But up to you.? : ) > > Thanks, > Patricio >> Thanks again, >> Richard. >> >> -----Original Message----- >> From: Patricio Chilano >> Sent: Donnerstag, 13. Februar 2020 18:47 >> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Richard, >> >> I?m only commenting on the handshake changes. >> I see that operation VM_EnterInterpOnlyMode can be called inside >> operation VM_SetFramePop which also allows nested operations. Here is a >> comment in VM_SetFramePop definition: >> >> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >> >> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >> could have a handshake inside a safepoint operation. The issue I see >> there is that at the end of the handshake the polling page of the target >> thread could be disarmed. So if the target thread happens to be in a >> blocked state just transiently and wakes up then it will not stop for >> the ongoing safepoint. Maybe I can file an RFE to assert that the >> polling page is armed at the beginning of disarm_safepoint(). >> >> I think one option could be to remove >> SafepointMechanism::disarm_if_needed() in >> HandshakeState::clear_handshake() and let each JavaThread disarm itself >> for the handshake case. >> >> Alternatively I think you could do something similar to what we do in >> Deoptimization::deoptimize_all_marked(): >> >> ? EnterInterpOnlyModeClosure hs; >> ? if (SafepointSynchronize::is_at_safepoint()) { >> ??? hs.do_thread(state->get_thread()); >> ? } else { >> ??? Handshake::execute(&hs, state->get_thread()); >> ? } >> (you could pass ?EnterInterpOnlyModeClosure? directly to the >> HandshakeClosure() constructor) >> >> I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >> always called in a nested operation or just sometimes. >> >> Thanks, >> Patricio >> >> On 2/12/20 7:23 AM, Reingruber, Richard wrote: >>> // Repost including hotspot runtime and gc lists. >>> // Dean Long suggested to do so, because the enhancement replaces a vm operation >>> // with a handshake. >>> // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html >>> >>> Hi, >>> >>> could I please get reviews for this small enhancement in hotspot's jvmti implementation: >>> >>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >>> >>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to >>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. >>> >>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. >>> >>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>> >>> Thanks, Richard. >>> >>> See also my question if anyone knows a reason for making the compiled methods not_entrant: >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html > From suenaga at oss.nttdata.com Fri Apr 24 15:23:06 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Sat, 25 Apr 2020 00:23:06 +0900 Subject: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant In-Reply-To: References: <3c59b9f9-ec38-18c9-8f24-e1186a08a04a@oracle.com> <410eed04-e2ef-0f4f-1c56-19e6734a10f6@oracle.com> Message-ID: <81d7caa8-4244-85f3-4d4e-78117fe5e25b@oss.nttdata.com> Hi Richard, On 2020/04/24 23:44, Reingruber, Richard wrote: > Hi Yasumasa, > >> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >> Does it help you? I think it gives you to remove workaround. > > I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake > you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to > change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. Thanks for your information. I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. I will modify and will test it after yours. > Also my first impression was that it won't be that easy from a synchronization point of view to > replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls > JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where > JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear > to me, how this has to be handled. I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. Thanks, Yasumasa > So it appears to me that it would be easier to push JDK-8242427 after this (JDK-8238585). > >> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) > > Would be interesting to see how you handled the issues above :) > > Thanks, Richard. > > [1] See question in comment https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030 > > -----Original Message----- > From: Yasumasa Suenaga > Sent: Freitag, 24. April 2020 13:34 > To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Richard, > > I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. > Does it help you? I think it gives you to remove workaround. > > (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) > > > Thanks, > > Yasumasa > > > On 2020/04/24 17:18, Reingruber, Richard wrote: >> Hi Patricio, Vladimir, and Serguei, >> >> now that direct handshakes are available, I've updated the patch to make use of them. >> >> In addition I have done some clean-up changes I missed in the first webrev. >> >> Finally I have implemented the workaround suggested by Patricio to avoid nesting the handshake >> into the vm operation VM_SetFramePop [1] >> >> Kindly review again: >> >> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ >> Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ >> >> I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode can be replaced with a >> direct handshake: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8238585 >> >> Testing: >> >> * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >> >> * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737 >> >> Thanks, >> Richard. >> >> [1] An assertion in Handshake::execute_direct() fails, if called be VMThread, because it is no JavaThread. >> >> -----Original Message----- >> From: hotspot-dev On Behalf Of Reingruber, Richard >> Sent: Freitag, 14. Februar 2020 19:47 >> To: Patricio Chilano ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Patricio, >> >> > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >> > > handshake cannot be nested in a vm operation. Maybe it should be asserted in the >> > > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >> > > >> > > > Alternatively I think you could do something similar to what we do in >> > > > Deoptimization::deoptimize_all_marked(): >> > > > >> > > > EnterInterpOnlyModeClosure hs; >> > > > if (SafepointSynchronize::is_at_safepoint()) { >> > > > hs.do_thread(state->get_thread()); >> > > > } else { >> > > > Handshake::execute(&hs, state->get_thread()); >> > > > } >> > > > (you could pass ?EnterInterpOnlyModeClosure? directly to the >> > > > HandshakeClosure() constructor) >> > > >> > > Maybe this could be used also in the Handshake::execute() methods as general solution? >> > Right, we could also do that. Avoiding to clear the polling page in >> > HandshakeState::clear_handshake() should be enough to fix this issue and >> > execute a handshake inside a safepoint, but adding that "if" statement >> > in Hanshake::execute() sounds good to avoid all the extra code that we >> > go through when executing a handshake. I filed 8239084 to make that change. >> >> Thanks for taking care of this and creating the RFE. >> >> > >> > > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >> > > > always called in a nested operation or just sometimes. >> > > >> > > At least one execution path without vm operation exists: >> > > >> > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >> > > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >> > > JvmtiEventControllerPrivate::recompute_enabled() : void >> > > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >> > > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >> > > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >> > > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >> > > >> > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >> > > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >> > > encouraged to do it with a handshake :) >> > Ah! I think you can still do it with a handshake with the >> > Deoptimization::deoptimize_all_marked() like solution. I can change the >> > if-else statement with just the Handshake::execute() call in 8239084. >> > But up to you. : ) >> >> Well, I think that's enough encouragement :) >> I'll wait for 8239084 and try then again. >> (no urgency and all) >> >> Thanks, >> Richard. >> >> -----Original Message----- >> From: Patricio Chilano >> Sent: Freitag, 14. Februar 2020 15:54 >> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Richard, >> >> On 2/14/20 9:58 AM, Reingruber, Richard wrote: >>> Hi Patricio, >>> >>> thanks for having a look. >>> >>> > I?m only commenting on the handshake changes. >>> > I see that operation VM_EnterInterpOnlyMode can be called inside >>> > operation VM_SetFramePop which also allows nested operations. Here is a >>> > comment in VM_SetFramePop definition: >>> > >>> > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>> > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>> > >>> > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>> > could have a handshake inside a safepoint operation. The issue I see >>> > there is that at the end of the handshake the polling page of the target >>> > thread could be disarmed. So if the target thread happens to be in a >>> > blocked state just transiently and wakes up then it will not stop for >>> > the ongoing safepoint. Maybe I can file an RFE to assert that the >>> > polling page is armed at the beginning of disarm_safepoint(). >>> >>> I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>> handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>> Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>> >>> > Alternatively I think you could do something similar to what we do in >>> > Deoptimization::deoptimize_all_marked(): >>> > >>> > EnterInterpOnlyModeClosure hs; >>> > if (SafepointSynchronize::is_at_safepoint()) { >>> > hs.do_thread(state->get_thread()); >>> > } else { >>> > Handshake::execute(&hs, state->get_thread()); >>> > } >>> > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>> > HandshakeClosure() constructor) >>> >>> Maybe this could be used also in the Handshake::execute() methods as general solution? >> Right, we could also do that. Avoiding to clear the polling page in >> HandshakeState::clear_handshake() should be enough to fix this issue and >> execute a handshake inside a safepoint, but adding that "if" statement >> in Hanshake::execute() sounds good to avoid all the extra code that we >> go through when executing a handshake. I filed 8239084 to make that change. >> >>> > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>> > always called in a nested operation or just sometimes. >>> >>> At least one execution path without vm operation exists: >>> >>> JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>> JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>> JvmtiEventControllerPrivate::recompute_enabled() : void >>> JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>> JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>> JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>> jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>> >>> I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>> handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>> encouraged to do it with a handshake :) >> Ah! I think you can still do it with a handshake with the >> Deoptimization::deoptimize_all_marked() like solution. I can change the >> if-else statement with just the Handshake::execute() call in 8239084. >> But up to you.? : ) >> >> Thanks, >> Patricio >>> Thanks again, >>> Richard. >>> >>> -----Original Message----- >>> From: Patricio Chilano >>> Sent: Donnerstag, 13. Februar 2020 18:47 >>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Richard, >>> >>> I?m only commenting on the handshake changes. >>> I see that operation VM_EnterInterpOnlyMode can be called inside >>> operation VM_SetFramePop which also allows nested operations. Here is a >>> comment in VM_SetFramePop definition: >>> >>> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>> >>> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>> could have a handshake inside a safepoint operation. The issue I see >>> there is that at the end of the handshake the polling page of the target >>> thread could be disarmed. So if the target thread happens to be in a >>> blocked state just transiently and wakes up then it will not stop for >>> the ongoing safepoint. Maybe I can file an RFE to assert that the >>> polling page is armed at the beginning of disarm_safepoint(). >>> >>> I think one option could be to remove >>> SafepointMechanism::disarm_if_needed() in >>> HandshakeState::clear_handshake() and let each JavaThread disarm itself >>> for the handshake case. >>> >>> Alternatively I think you could do something similar to what we do in >>> Deoptimization::deoptimize_all_marked(): >>> >>> ? EnterInterpOnlyModeClosure hs; >>> ? if (SafepointSynchronize::is_at_safepoint()) { >>> ??? hs.do_thread(state->get_thread()); >>> ? } else { >>> ??? Handshake::execute(&hs, state->get_thread()); >>> ? } >>> (you could pass ?EnterInterpOnlyModeClosure? directly to the >>> HandshakeClosure() constructor) >>> >>> I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>> always called in a nested operation or just sometimes. >>> >>> Thanks, >>> Patricio >>> >>> On 2/12/20 7:23 AM, Reingruber, Richard wrote: >>>> // Repost including hotspot runtime and gc lists. >>>> // Dean Long suggested to do so, because the enhancement replaces a vm operation >>>> // with a handshake. >>>> // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html >>>> >>>> Hi, >>>> >>>> could I please get reviews for this small enhancement in hotspot's jvmti implementation: >>>> >>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >>>> >>>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to >>>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. >>>> >>>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. >>>> >>>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>>> >>>> Thanks, Richard. >>>> >>>> See also my question if anyone knows a reason for making the compiled methods not_entrant: >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html >> From richard.reingruber at sap.com Fri Apr 24 16:08:57 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 24 Apr 2020 16:08:57 +0000 Subject: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant In-Reply-To: <81d7caa8-4244-85f3-4d4e-78117fe5e25b@oss.nttdata.com> References: <3c59b9f9-ec38-18c9-8f24-e1186a08a04a@oracle.com> <410eed04-e2ef-0f4f-1c56-19e6734a10f6@oracle.com> <81d7caa8-4244-85f3-4d4e-78117fe5e25b@oss.nttdata.com> Message-ID: Hi Yasumasa, Patricio, > >> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. > >> Does it help you? I think it gives you to remove workaround. > > > > I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake > > you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to > > change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. > Thanks for your information. > I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. > I will modify and will test it after yours. Thanks :) > > Also my first impression was that it won't be that easy from a synchronization point of view to > > replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls > > JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where > > JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear > > to me, how this has to be handled. > I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. Yes. To me it is unclear what synchronization is necessary, if it is called during a handshake. And also I'm unsure if a thread should do safepoint checks while executing a handshake. @Patricio, coming back to my question [1]: In the example you gave in your answer [2]: the java thread would execute a vm operation during a direct handshake operation, while the VMThread is actually in the middle of a VM_HandshakeAllThreads operation, waiting to handshake the same handshakee: why can't the VMThread just proceed? The handshakee would be safepoint safe, wouldn't it? Thanks, Richard. [1] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301677&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301677 [2] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301763&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301763 -----Original Message----- From: Yasumasa Suenaga Sent: Freitag, 24. April 2020 17:23 To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant Hi Richard, On 2020/04/24 23:44, Reingruber, Richard wrote: > Hi Yasumasa, > >> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >> Does it help you? I think it gives you to remove workaround. > > I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake > you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to > change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. Thanks for your information. I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. I will modify and will test it after yours. > Also my first impression was that it won't be that easy from a synchronization point of view to > replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls > JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where > JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear > to me, how this has to be handled. I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. Thanks, Yasumasa > So it appears to me that it would be easier to push JDK-8242427 after this (JDK-8238585). > >> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) > > Would be interesting to see how you handled the issues above :) > > Thanks, Richard. > > [1] See question in comment https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030 > > -----Original Message----- > From: Yasumasa Suenaga > Sent: Freitag, 24. April 2020 13:34 > To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Richard, > > I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. > Does it help you? I think it gives you to remove workaround. > > (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) > > > Thanks, > > Yasumasa > > > On 2020/04/24 17:18, Reingruber, Richard wrote: >> Hi Patricio, Vladimir, and Serguei, >> >> now that direct handshakes are available, I've updated the patch to make use of them. >> >> In addition I have done some clean-up changes I missed in the first webrev. >> >> Finally I have implemented the workaround suggested by Patricio to avoid nesting the handshake >> into the vm operation VM_SetFramePop [1] >> >> Kindly review again: >> >> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ >> Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ >> >> I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode can be replaced with a >> direct handshake: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8238585 >> >> Testing: >> >> * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >> >> * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737 >> >> Thanks, >> Richard. >> >> [1] An assertion in Handshake::execute_direct() fails, if called be VMThread, because it is no JavaThread. >> >> -----Original Message----- >> From: hotspot-dev On Behalf Of Reingruber, Richard >> Sent: Freitag, 14. Februar 2020 19:47 >> To: Patricio Chilano ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Patricio, >> >> > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >> > > handshake cannot be nested in a vm operation. Maybe it should be asserted in the >> > > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >> > > >> > > > Alternatively I think you could do something similar to what we do in >> > > > Deoptimization::deoptimize_all_marked(): >> > > > >> > > > EnterInterpOnlyModeClosure hs; >> > > > if (SafepointSynchronize::is_at_safepoint()) { >> > > > hs.do_thread(state->get_thread()); >> > > > } else { >> > > > Handshake::execute(&hs, state->get_thread()); >> > > > } >> > > > (you could pass ?EnterInterpOnlyModeClosure? directly to the >> > > > HandshakeClosure() constructor) >> > > >> > > Maybe this could be used also in the Handshake::execute() methods as general solution? >> > Right, we could also do that. Avoiding to clear the polling page in >> > HandshakeState::clear_handshake() should be enough to fix this issue and >> > execute a handshake inside a safepoint, but adding that "if" statement >> > in Hanshake::execute() sounds good to avoid all the extra code that we >> > go through when executing a handshake. I filed 8239084 to make that change. >> >> Thanks for taking care of this and creating the RFE. >> >> > >> > > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >> > > > always called in a nested operation or just sometimes. >> > > >> > > At least one execution path without vm operation exists: >> > > >> > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >> > > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >> > > JvmtiEventControllerPrivate::recompute_enabled() : void >> > > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >> > > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >> > > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >> > > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >> > > >> > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >> > > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >> > > encouraged to do it with a handshake :) >> > Ah! I think you can still do it with a handshake with the >> > Deoptimization::deoptimize_all_marked() like solution. I can change the >> > if-else statement with just the Handshake::execute() call in 8239084. >> > But up to you. : ) >> >> Well, I think that's enough encouragement :) >> I'll wait for 8239084 and try then again. >> (no urgency and all) >> >> Thanks, >> Richard. >> >> -----Original Message----- >> From: Patricio Chilano >> Sent: Freitag, 14. Februar 2020 15:54 >> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Richard, >> >> On 2/14/20 9:58 AM, Reingruber, Richard wrote: >>> Hi Patricio, >>> >>> thanks for having a look. >>> >>> > I?m only commenting on the handshake changes. >>> > I see that operation VM_EnterInterpOnlyMode can be called inside >>> > operation VM_SetFramePop which also allows nested operations. Here is a >>> > comment in VM_SetFramePop definition: >>> > >>> > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>> > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>> > >>> > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>> > could have a handshake inside a safepoint operation. The issue I see >>> > there is that at the end of the handshake the polling page of the target >>> > thread could be disarmed. So if the target thread happens to be in a >>> > blocked state just transiently and wakes up then it will not stop for >>> > the ongoing safepoint. Maybe I can file an RFE to assert that the >>> > polling page is armed at the beginning of disarm_safepoint(). >>> >>> I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>> handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>> Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>> >>> > Alternatively I think you could do something similar to what we do in >>> > Deoptimization::deoptimize_all_marked(): >>> > >>> > EnterInterpOnlyModeClosure hs; >>> > if (SafepointSynchronize::is_at_safepoint()) { >>> > hs.do_thread(state->get_thread()); >>> > } else { >>> > Handshake::execute(&hs, state->get_thread()); >>> > } >>> > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>> > HandshakeClosure() constructor) >>> >>> Maybe this could be used also in the Handshake::execute() methods as general solution? >> Right, we could also do that. Avoiding to clear the polling page in >> HandshakeState::clear_handshake() should be enough to fix this issue and >> execute a handshake inside a safepoint, but adding that "if" statement >> in Hanshake::execute() sounds good to avoid all the extra code that we >> go through when executing a handshake. I filed 8239084 to make that change. >> >>> > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>> > always called in a nested operation or just sometimes. >>> >>> At least one execution path without vm operation exists: >>> >>> JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>> JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>> JvmtiEventControllerPrivate::recompute_enabled() : void >>> JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>> JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>> JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>> jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>> >>> I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>> handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>> encouraged to do it with a handshake :) >> Ah! I think you can still do it with a handshake with the >> Deoptimization::deoptimize_all_marked() like solution. I can change the >> if-else statement with just the Handshake::execute() call in 8239084. >> But up to you.? : ) >> >> Thanks, >> Patricio >>> Thanks again, >>> Richard. >>> >>> -----Original Message----- >>> From: Patricio Chilano >>> Sent: Donnerstag, 13. Februar 2020 18:47 >>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Richard, >>> >>> I?m only commenting on the handshake changes. >>> I see that operation VM_EnterInterpOnlyMode can be called inside >>> operation VM_SetFramePop which also allows nested operations. Here is a >>> comment in VM_SetFramePop definition: >>> >>> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>> >>> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>> could have a handshake inside a safepoint operation. The issue I see >>> there is that at the end of the handshake the polling page of the target >>> thread could be disarmed. So if the target thread happens to be in a >>> blocked state just transiently and wakes up then it will not stop for >>> the ongoing safepoint. Maybe I can file an RFE to assert that the >>> polling page is armed at the beginning of disarm_safepoint(). >>> >>> I think one option could be to remove >>> SafepointMechanism::disarm_if_needed() in >>> HandshakeState::clear_handshake() and let each JavaThread disarm itself >>> for the handshake case. >>> >>> Alternatively I think you could do something similar to what we do in >>> Deoptimization::deoptimize_all_marked(): >>> >>> ? EnterInterpOnlyModeClosure hs; >>> ? if (SafepointSynchronize::is_at_safepoint()) { >>> ??? hs.do_thread(state->get_thread()); >>> ? } else { >>> ??? Handshake::execute(&hs, state->get_thread()); >>> ? } >>> (you could pass ?EnterInterpOnlyModeClosure? directly to the >>> HandshakeClosure() constructor) >>> >>> I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>> always called in a nested operation or just sometimes. >>> >>> Thanks, >>> Patricio >>> >>> On 2/12/20 7:23 AM, Reingruber, Richard wrote: >>>> // Repost including hotspot runtime and gc lists. >>>> // Dean Long suggested to do so, because the enhancement replaces a vm operation >>>> // with a handshake. >>>> // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html >>>> >>>> Hi, >>>> >>>> could I please get reviews for this small enhancement in hotspot's jvmti implementation: >>>> >>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >>>> >>>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to >>>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. >>>> >>>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. >>>> >>>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>>> >>>> Thanks, Richard. >>>> >>>> See also my question if anyone knows a reason for making the compiled methods not_entrant: >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html >> From patricio.chilano.mateo at oracle.com Fri Apr 24 17:13:43 2020 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Fri, 24 Apr 2020 14:13:43 -0300 Subject: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant In-Reply-To: References: <3c59b9f9-ec38-18c9-8f24-e1186a08a04a@oracle.com> <410eed04-e2ef-0f4f-1c56-19e6734a10f6@oracle.com> <81d7caa8-4244-85f3-4d4e-78117fe5e25b@oss.nttdata.com> Message-ID: <11c78b30-de04-544d-3a10-811ebf663bf2@oracle.com> Hi Richard, Just jumping into your last question for now.? : ) On 4/24/20 1:08 PM, Reingruber, Richard wrote: > Hi Yasumasa, Patricio, > >>>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>>> Does it help you? I think it gives you to remove workaround. >>> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >>> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. >> Thanks for your information. >> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. >> I will modify and will test it after yours. > Thanks :) > >>> Also my first impression was that it won't be that easy from a synchronization point of view to >>> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >>> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >>> to me, how this has to be handled. >> I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. > Yes. To me it is unclear what synchronization is necessary, if it is called during a handshake. And > also I'm unsure if a thread should do safepoint checks while executing a handshake. > > @Patricio, coming back to my question [1]: > > In the example you gave in your answer [2]: the java thread would execute a vm operation during a > direct handshake operation, while the VMThread is actually in the middle of a VM_HandshakeAllThreads > operation, waiting to handshake the same handshakee: why can't the VMThread just proceed? The > handshakee would be safepoint safe, wouldn't it? Because the VMThread would not be able to decrement _processing_sem to claim the operation and execute the closure for that handshakee. If another JavaThread is doing a direct handshake with that same handshakee and called a new VM operation inside the execution of the HandshakeClosure in do_handshake(), nobody would be able to decrement the _processing_sem anymore until the original direct operation finished and the semaphore is signaled again. So this can happen despite the state of the handshakee is "handshake/safepoint safe". Changing the nested VM operation to be a direct handshake would have the same issue. Actually as the code is right now we would not even get pass setting the handshake operation because in that case we would block in the _handshake_turn_sem for the same reason. So changing VM_SetFramePop to use direct handshakes in the future will probably create that last issue I mentioned. Now, since it is executed at a safepoint, with your workaround in enter_interp_only_mode() we avoid those nested issues in . Maybe 8239084 would have to be revisited to address nested operations in all cases. It is not clear to me now though if we should handle that in the handshake code or the caller of a certain operation should know it might be called in a nested scenario and should handle it. I'll look a bit more at the updated patch but at first glance looks good. Thanks! Patricio > Thanks, Richard. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301677&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301677 > > [2] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301763&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301763 > > -----Original Message----- > From: Yasumasa Suenaga > Sent: Freitag, 24. April 2020 17:23 > To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Richard, > > On 2020/04/24 23:44, Reingruber, Richard wrote: >> Hi Yasumasa, >> >>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>> Does it help you? I think it gives you to remove workaround. >> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. > Thanks for your information. > I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. > I will modify and will test it after yours. > > >> Also my first impression was that it won't be that easy from a synchronization point of view to >> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >> to me, how this has to be handled. > I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. > > > Thanks, > > Yasumasa > > >> So it appears to me that it would be easier to push JDK-8242427 after this (JDK-8238585). >> >>> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >> Would be interesting to see how you handled the issues above :) >> >> Thanks, Richard. >> >> [1] See question in comment https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030 >> >> -----Original Message----- >> From: Yasumasa Suenaga >> Sent: Freitag, 24. April 2020 13:34 >> To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Richard, >> >> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >> Does it help you? I think it gives you to remove workaround. >> >> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/24 17:18, Reingruber, Richard wrote: >>> Hi Patricio, Vladimir, and Serguei, >>> >>> now that direct handshakes are available, I've updated the patch to make use of them. >>> >>> In addition I have done some clean-up changes I missed in the first webrev. >>> >>> Finally I have implemented the workaround suggested by Patricio to avoid nesting the handshake >>> into the vm operation VM_SetFramePop [1] >>> >>> Kindly review again: >>> >>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ >>> Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ >>> >>> I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode can be replaced with a >>> direct handshake: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238585 >>> >>> Testing: >>> >>> * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>> >>> * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737 >>> >>> Thanks, >>> Richard. >>> >>> [1] An assertion in Handshake::execute_direct() fails, if called be VMThread, because it is no JavaThread. >>> >>> -----Original Message----- >>> From: hotspot-dev On Behalf Of Reingruber, Richard >>> Sent: Freitag, 14. Februar 2020 19:47 >>> To: Patricio Chilano ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Patricio, >>> >>> > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>> > > handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>> > > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>> > > >>> > > > Alternatively I think you could do something similar to what we do in >>> > > > Deoptimization::deoptimize_all_marked(): >>> > > > >>> > > > EnterInterpOnlyModeClosure hs; >>> > > > if (SafepointSynchronize::is_at_safepoint()) { >>> > > > hs.do_thread(state->get_thread()); >>> > > > } else { >>> > > > Handshake::execute(&hs, state->get_thread()); >>> > > > } >>> > > > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>> > > > HandshakeClosure() constructor) >>> > > >>> > > Maybe this could be used also in the Handshake::execute() methods as general solution? >>> > Right, we could also do that. Avoiding to clear the polling page in >>> > HandshakeState::clear_handshake() should be enough to fix this issue and >>> > execute a handshake inside a safepoint, but adding that "if" statement >>> > in Hanshake::execute() sounds good to avoid all the extra code that we >>> > go through when executing a handshake. I filed 8239084 to make that change. >>> >>> Thanks for taking care of this and creating the RFE. >>> >>> > >>> > > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>> > > > always called in a nested operation or just sometimes. >>> > > >>> > > At least one execution path without vm operation exists: >>> > > >>> > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>> > > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>> > > JvmtiEventControllerPrivate::recompute_enabled() : void >>> > > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>> > > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>> > > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>> > > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>> > > >>> > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>> > > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>> > > encouraged to do it with a handshake :) >>> > Ah! I think you can still do it with a handshake with the >>> > Deoptimization::deoptimize_all_marked() like solution. I can change the >>> > if-else statement with just the Handshake::execute() call in 8239084. >>> > But up to you. : ) >>> >>> Well, I think that's enough encouragement :) >>> I'll wait for 8239084 and try then again. >>> (no urgency and all) >>> >>> Thanks, >>> Richard. >>> >>> -----Original Message----- >>> From: Patricio Chilano >>> Sent: Freitag, 14. Februar 2020 15:54 >>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Richard, >>> >>> On 2/14/20 9:58 AM, Reingruber, Richard wrote: >>>> Hi Patricio, >>>> >>>> thanks for having a look. >>>> >>>> > I?m only commenting on the handshake changes. >>>> > I see that operation VM_EnterInterpOnlyMode can be called inside >>>> > operation VM_SetFramePop which also allows nested operations. Here is a >>>> > comment in VM_SetFramePop definition: >>>> > >>>> > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>> > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>> > >>>> > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>> > could have a handshake inside a safepoint operation. The issue I see >>>> > there is that at the end of the handshake the polling page of the target >>>> > thread could be disarmed. So if the target thread happens to be in a >>>> > blocked state just transiently and wakes up then it will not stop for >>>> > the ongoing safepoint. Maybe I can file an RFE to assert that the >>>> > polling page is armed at the beginning of disarm_safepoint(). >>>> >>>> I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>>> handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>>> Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>>> >>>> > Alternatively I think you could do something similar to what we do in >>>> > Deoptimization::deoptimize_all_marked(): >>>> > >>>> > EnterInterpOnlyModeClosure hs; >>>> > if (SafepointSynchronize::is_at_safepoint()) { >>>> > hs.do_thread(state->get_thread()); >>>> > } else { >>>> > Handshake::execute(&hs, state->get_thread()); >>>> > } >>>> > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>> > HandshakeClosure() constructor) >>>> >>>> Maybe this could be used also in the Handshake::execute() methods as general solution? >>> Right, we could also do that. Avoiding to clear the polling page in >>> HandshakeState::clear_handshake() should be enough to fix this issue and >>> execute a handshake inside a safepoint, but adding that "if" statement >>> in Hanshake::execute() sounds good to avoid all the extra code that we >>> go through when executing a handshake. I filed 8239084 to make that change. >>> >>>> > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>> > always called in a nested operation or just sometimes. >>>> >>>> At least one execution path without vm operation exists: >>>> >>>> JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>>> JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>>> JvmtiEventControllerPrivate::recompute_enabled() : void >>>> JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>>> JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>>> JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>>> jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>>> >>>> I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>>> handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>>> encouraged to do it with a handshake :) >>> Ah! I think you can still do it with a handshake with the >>> Deoptimization::deoptimize_all_marked() like solution. I can change the >>> if-else statement with just the Handshake::execute() call in 8239084. >>> But up to you.? : ) >>> >>> Thanks, >>> Patricio >>>> Thanks again, >>>> Richard. >>>> >>>> -----Original Message----- >>>> From: Patricio Chilano >>>> Sent: Donnerstag, 13. Februar 2020 18:47 >>>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>>> >>>> Hi Richard, >>>> >>>> I?m only commenting on the handshake changes. >>>> I see that operation VM_EnterInterpOnlyMode can be called inside >>>> operation VM_SetFramePop which also allows nested operations. Here is a >>>> comment in VM_SetFramePop definition: >>>> >>>> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>> >>>> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>> could have a handshake inside a safepoint operation. The issue I see >>>> there is that at the end of the handshake the polling page of the target >>>> thread could be disarmed. So if the target thread happens to be in a >>>> blocked state just transiently and wakes up then it will not stop for >>>> the ongoing safepoint. Maybe I can file an RFE to assert that the >>>> polling page is armed at the beginning of disarm_safepoint(). >>>> >>>> I think one option could be to remove >>>> SafepointMechanism::disarm_if_needed() in >>>> HandshakeState::clear_handshake() and let each JavaThread disarm itself >>>> for the handshake case. >>>> >>>> Alternatively I think you could do something similar to what we do in >>>> Deoptimization::deoptimize_all_marked(): >>>> >>>> ? EnterInterpOnlyModeClosure hs; >>>> ? if (SafepointSynchronize::is_at_safepoint()) { >>>> ??? hs.do_thread(state->get_thread()); >>>> ? } else { >>>> ??? Handshake::execute(&hs, state->get_thread()); >>>> ? } >>>> (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>> HandshakeClosure() constructor) >>>> >>>> I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>> always called in a nested operation or just sometimes. >>>> >>>> Thanks, >>>> Patricio >>>> >>>> On 2/12/20 7:23 AM, Reingruber, Richard wrote: >>>>> // Repost including hotspot runtime and gc lists. >>>>> // Dean Long suggested to do so, because the enhancement replaces a vm operation >>>>> // with a handshake. >>>>> // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html >>>>> >>>>> Hi, >>>>> >>>>> could I please get reviews for this small enhancement in hotspot's jvmti implementation: >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >>>>> >>>>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to >>>>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. >>>>> >>>>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. >>>>> >>>>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>>>> >>>>> Thanks, Richard. >>>>> >>>>> See also my question if anyone knows a reason for making the compiled methods not_entrant: >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html From chris.plummer at oracle.com Fri Apr 24 18:30:31 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 24 Apr 2020 11:30:31 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same In-Reply-To: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> References: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> Message-ID: Hi Daniil, ? 84???????????? // If new MBean (e.g. Graal MBean) is registred while the test is running names1, ?106???????????? // If new MBean (e.g. Graal MBean) is registred while the test is running mbeans1, registred -> registered ',' after "running" Just wondering how you chose 10 as the number of retries. Seems excessive. Shouldn't the problem turn up at most 1 time and therefore only 1 retry is needed. ? 76???????? int counter = 0; ? 86???????????? if (sameSize(names1, names2, names3) || counter++ > MAX_RETRY_ATTEMPTS) { The way the checks are done you will actually end up retrying MAX_RETRY_ATTEMPTS+1 times. For example, if MAX_RETRY_ATTEMPTS is 1, first time through the loop counter is 0 so a retry is allowed. Second time through the loop counter is 1, so a retry is allowed again. thanks, Chris On 4/18/20 11:30 AM, Daniil Titov wrote: > Please review the change that fixes the failure of javax/management/generified/GenericTest.java and > javax/management/query/CustomQueryTest.java tests when Graal is on. > > The tests checks that calls of management API are consistent and return the same set of MBeans. However, > when Graal is on the Graal MBean might be registered between the calls that in turn makes the results > inconsistent and the tests fail. > > The fix makes the test aware that some MBean might be registered while the checks run and if it happens the tests repeat the check. > > Testing : Mach5 tests with Graal on and tier1-tier3 tests passed. > > [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.01/ > [2] https://bugs.openjdk.java.net/browse/JDK-8242239 > > Thanks, > Daniil > > > > From serguei.spitsyn at oracle.com Fri Apr 24 18:31:28 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Apr 2020 11:31:28 -0700 Subject: RFR (S): 8242237: Improve JVM TI HiddenClasses tests In-Reply-To: References: Message-ID: <84d00dbf-a6e4-3407-6f8e-f3faa4c92e5c@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Apr 24 18:48:56 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Apr 2020 11:48:56 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same In-Reply-To: References: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> Message-ID: <9deb907b-0cbb-2a05-73a3-1aa4c6f5fc94@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Fri Apr 24 19:36:42 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 24 Apr 2020 12:36:42 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same In-Reply-To: <9deb907b-0cbb-2a05-73a3-1aa4c6f5fc94@oracle.com> References: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> <9deb907b-0cbb-2a05-73a3-1aa4c6f5fc94@oracle.com> Message-ID: Hi Serguei and Chris, Thank you for your comments. I wanted to make the fix ?more generic ?and not limit it just to Graal management bean. In this case we could expect that after the first retry is triggered by Graal MBean registration some other ?lazy-registered? MBean got registered and the test might fail. To avoid this we need to allow test to make at least several retry attempts before failing.? If number 10 looks as too high we could make it 5 or even 3. This should not affect the test run-time unless the test starts failing for some other reason than we expect. ?In the new webrev I will also correct ?the iteration counting (as Chris mentioned) and fix typos. Thanks again, Daniil From: "serguei.spitsyn at oracle.com" Date: Friday, April 24, 2020 at 11:48 AM To: Chris Plummer , Daniil Titov , serviceability-dev Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same Hi Daniil, Besides what Chris is pointed out the fix looks good. Minor: ? 97???????? while(true) { 113???????????? if(mbeanCount * 2 == counterCount || retryCounter++ > MAX_RETRY_ATTEMPT) { 114???????????????? assertEquals(mbeanCount * 2, counterCount); Space is missed in while and if. I doubt, the assert is really needed. ? 96???????? // is running ( e.g. Graal MBean). In this case just retry the test. Extra space before "e.g.". Thanks, Serguei On 4/24/20 11:30, Chris Plummer wrote: Hi Daniil, 84 // If new MBean (e.g. Graal MBean) is registred while the test is running names1, 106 // If new MBean (e.g. Graal MBean) is registred while the test is running mbeans1, registred -> registered ',' after "running" Just wondering how you chose 10 as the number of retries. Seems excessive. Shouldn't the problem turn up at most 1 time and therefore only 1 retry is needed. 76 int counter = 0; 86 if (sameSize(names1, names2, names3) || counter++ > MAX_RETRY_ATTEMPTS) { The way the checks are done you will actually end up retrying MAX_RETRY_ATTEMPTS+1 times. For example, if MAX_RETRY_ATTEMPTS is 1, first time through the loop counter is 0 so a retry is allowed. Second time through the loop counter is 1, so a retry is allowed again. thanks, Chris On 4/18/20 11:30 AM, Daniil Titov wrote: Please review the change that fixes the failure of javax/management/generified/GenericTest.java and javax/management/query/CustomQueryTest.java tests when Graal is on. The tests checks that calls of management API are consistent and return the same set of MBeans. However, when Graal is on the Graal MBean might be registered between the calls that in turn makes the results inconsistent and the tests fail. The fix makes the test aware that some MBean might be registered while the checks run and if it happens the tests repeat the check. Testing : Mach5 tests with Graal on and tier1-tier3 tests passed. [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8242239 Thanks, Daniil -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Fri Apr 24 20:20:17 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 24 Apr 2020 13:20:17 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: References: Message-ID: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> Hi I have several comments about coding and desing. These tests might be used as examples for new JDI tests based on this framework so I think it would be better to polish them. General comment: 1. You often check results (not null, exactly one result). It makes sense to use jdk.test.lib.Asserts for such verification. Just to reduce number of code and fail with standard exceptions. 2. Wildcard imports like 'import com.sun.jdi.*;' are not recommended. 3. I recommend to catch Throwable instead of Exception especially in non-main threads. Just to ensure that nothing is missed. 4. nsk.share.Failure is subclass of RuntimeException so you don't need to add it to throws. Now sometimes it is added, sometimes not. It looks inconsistent. 5. There are lot of code duplication in debugger and debugge classes. Does it make a sense to merge it into base classes? http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001.java.html 6. The getField can't return null, it verifies result. So check in line 191-193 is not needed. 190 Field field = getField(hcRefType, "hcField"); ?191 if (field == null) { 192 throw new Failure("TEST FAILED: cannot enable ModificationWhatchpointRequest: hcField not found"); 193 } 7. I would recommend to move all initialization from run in constructor and make most of variable 'final' it helps to ensure that they are initialized. 297 public int run(final String args[], final PrintStream out) { 298 ArgumentHandler argHandler = new ArgumentHandler(args); 299 300 log = new Log(out, argHandler); 301 eventTimeout = argHandler.getWaitTime() * 60 * 1000; // milliseconds 302 launchDebuggee(argHandler); 8. Pair looks inconsistent. start saves handler as class field while join use as parameter. 305 startEventHandler(); 330 joinEventHandler(eventHandler); I think that something like EventHandler eventHandler = startEventHandler(); joinEventHandler(eventHandler); looks better and restrict usage of eventHandler. You also migt move methods startEventHandler into EventHandler itself. 9. I suggest to make setHCRefType private and rename getHCRefType to something like receiveHCRefType. To make more clear that it is not a simple getter, but method which wait for event. 361 // Save hidden class ReferenceType when its ClassPrepare event is received. 362 synchronized void setHCRefType(ReferenceType type) { 363 hcRefType = type; 364 notifyAll(); 365 } 366 367 // This method is used by the debugger main thread to wait and get 368 // the hidden class reference type from its ClassPrepare event. 369 // The readyCmdSync with the debuggeee is not enough because a 370 // ClassPrepare event sent over JDWP protocol has some delay. 371 // A wait/notify sync is to ensure the debugger gets non-null value. 372 synchronized ReferenceType getHCRefType() { 373 try { 374 while (hcRefType == null) { 375 wait(); 376 } 377 } catch (InterruptedException ie) { 378 throw new Failure("Unexpected InterruptedException in waiting for HC prepare: " + ie); 379 } 380 return hcRefType; 381 } 10. We don't run tests with -ea/esa so assertions usually disabled. Use Assertions from test lib instead. The comment 1) is recommendation only but 'assert' is just ignored. 436 assert name.indexOf("HiddenClass") > 0 && name.indexOf("/0x") > 0; http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001a.java.html 11. Check if jdk.test.lib.classloader.ClassLoadUtils. getClassPath(String className) works for you instead of 70 private static String getClassPath(Class klass) { 12. You could use try(log = new PrintStream("Debuggee.log")) {} here: 82 log = new PrintStream("Debuggee.log"); .. 86 try { .. ?90 } 91 log.close(); 13. It is better to throw RuntimeException and don't add throws Exception in all methods. 95 private void syncWithDebugger(IOPipe pipe) throws Exception { http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent/classUnloadEvent001a.java.html You could use single if for this. 122 if (command == null) { 123 throw new Exception("Failed: pipe.readln() returned null instead of COMMAND_QUIT"); 124 } else if (!command.equals(classUnloadEvent001.COMMAND_QUIT)) { 125 throw new Exception("Failed COMMAND_QUIT sync with debugger, got unknown command: " + command); 126 } 14. Setting to null is not required to collect objects here. 151 hcObj = null; 152 hc = null; Probably I didn't catch all issues, but let discuss this list first. Leonid On 4/23/20 9:01 PM, serguei.spitsyn at oracle.com wrote: > Please, review a fix for the sub-task: > https://bugs.openjdk.java.net/browse/JDK-8241807 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/ > > > Summary; > ? This sub-task is to cover any hidden class related remaining issues > in the JDI and JDWP implementation. > ? In fact, no more issues were discovered with this extra test coverage. > ? So, this update includes only two new nsk jdi tests: > || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent > || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent > > ? These tests are to provide a test coverage? which was impossible to > provide with the jdb testing framework. > ? It includes ClassPrepare, Breakpoint and ModificationWatchpoint > events with class filters. > > Testing: > ? The mach5 job is in progress: > https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jdi-event-tests-20200424-0350-10464032 > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Apr 24 20:27:36 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 24 Apr 2020 13:27:36 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same In-Reply-To: References: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> <9deb907b-0cbb-2a05-73a3-1aa4c6f5fc94@oracle.com> Message-ID: <9523cda9-66a0-e609-f199-117f02d907d7@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Fri Apr 24 21:07:06 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 24 Apr 2020 14:07:06 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same In-Reply-To: <9523cda9-66a0-e609-f199-117f02d907d7@oracle.com> References: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> <9deb907b-0cbb-2a05-73a3-1aa4c6f5fc94@oracle.com> <9523cda9-66a0-e609-f199-117f02d907d7@oracle.com> Message-ID: <4E97D09F-D4EE-43E5-B30D-5DE4A3C7379B@oracle.com> Hi Chris, I agree with you. I will change the test to retry just once. Thank you, Daniil From: Chris Plummer Date: Friday, April 24, 2020 at 1:27 PM To: Daniil Titov , "serguei.spitsyn at oracle.com" , serviceability-dev Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same Hi Daniil, I think a retry count more in line with our current expectations would make more sense since it is deterministic how many retries are might actually be needed. You just used a large number in case more ?lazy-registered? mbeans are added in the future, but if this is the case then maybe even 10 is not enough. thanks, Chris On 4/24/20 12:36 PM, Daniil Titov wrote: Hi Serguei and Chris, Thank you for your comments. I wanted to make the fix more generic and not limit it just to Graal management bean. In this case we could expect that after the first retry is triggered by Graal MBean registration some other ?lazy-registered? MBean got registered and the test might fail. To avoid this we need to allow test to make at least several retry attempts before failing. If number 10 looks as too high we could make it 5 or even 3. This should not affect the test run-time unless the test starts failing for some other reason than we expect. In the new webrev I will also correct the iteration counting (as Chris mentioned) and fix typos. Thanks again, Daniil From: "serguei.spitsyn at oracle.com" Date: Friday, April 24, 2020 at 11:48 AM To: Chris Plummer , Daniil Titov , serviceability-dev Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same Hi Daniil, Besides what Chris is pointed out the fix looks good. Minor: 97 while(true) { 113 if(mbeanCount * 2 == counterCount || retryCounter++ > MAX_RETRY_ATTEMPT) { 114 assertEquals(mbeanCount * 2, counterCount); Space is missed in while and if. I doubt, the assert is really needed. 96 // is running ( e.g. Graal MBean). In this case just retry the test. Extra space before "e.g.". Thanks, Serguei On 4/24/20 11:30, Chris Plummer wrote: Hi Daniil, 84 // If new MBean (e.g. Graal MBean) is registred while the test is running names1, 106 // If new MBean (e.g. Graal MBean) is registred while the test is running mbeans1, registred -> registered ',' after "running" Just wondering how you chose 10 as the number of retries. Seems excessive. Shouldn't the problem turn up at most 1 time and therefore only 1 retry is needed. 76 int counter = 0; 86 if (sameSize(names1, names2, names3) || counter++ > MAX_RETRY_ATTEMPTS) { The way the checks are done you will actually end up retrying MAX_RETRY_ATTEMPTS+1 times. For example, if MAX_RETRY_ATTEMPTS is 1, first time through the loop counter is 0 so a retry is allowed. Second time through the loop counter is 1, so a retry is allowed again. thanks, Chris On 4/18/20 11:30 AM, Daniil Titov wrote: Please review the change that fixes the failure of javax/management/generified/GenericTest.java and javax/management/query/CustomQueryTest.java tests when Graal is on. The tests checks that calls of management API are consistent and return the same set of MBeans. However, when Graal is on the Graal MBean might be registered between the calls that in turn makes the results inconsistent and the tests fail. The fix makes the test aware that some MBean might be registered while the checks run and if it happens the tests repeat the check. Testing : Mach5 tests with Graal on and tier1-tier3 tests passed. [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8242239 Thanks, Daniil -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.reingruber at sap.com Fri Apr 24 21:41:45 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 24 Apr 2020 21:41:45 +0000 Subject: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant In-Reply-To: <11c78b30-de04-544d-3a10-811ebf663bf2@oracle.com> References: <3c59b9f9-ec38-18c9-8f24-e1186a08a04a@oracle.com> <410eed04-e2ef-0f4f-1c56-19e6734a10f6@oracle.com> <81d7caa8-4244-85f3-4d4e-78117fe5e25b@oss.nttdata.com> <11c78b30-de04-544d-3a10-811ebf663bf2@oracle.com> Message-ID: Hi Patricio, > > @Patricio, coming back to my question [1]: > > > > In the example you gave in your answer [2]: the java thread would execute a vm operation during a > > direct handshake operation, while the VMThread is actually in the middle of a VM_HandshakeAllThreads > > operation, waiting to handshake the same handshakee: why can't the VMThread just proceed? The > > handshakee would be safepoint safe, wouldn't it? > Because the VMThread would not be able to decrement _processing_sem to > claim the operation and execute the closure for that handshakee. If > another JavaThread is doing a direct handshake with that same handshakee > and called a new VM operation inside the execution of the > HandshakeClosure in do_handshake(), nobody would be able to decrement > the _processing_sem anymore until the original direct operation finished > and the semaphore is signaled again. Thanks, understood. On a higher level: a JavaThread can have at most one handshake operation being processed at at time. > So this can happen despite the > state of the handshakee is "handshake/safepoint safe". Changing the > nested VM operation to be a direct handshake would have the same issue. > Actually as the code is right now we would not even get pass setting the > handshake operation because in that case we would block in the > _handshake_turn_sem for the same reason. Don't really understand the details here, but that's ok. Interesting that _handshake_turn_sem gets signaled before or after do_handshake() depending if the handshake operation is processed by handshakee. Comments say "Disarm before/after executing operation" but not why :) > So changing VM_SetFramePop to use direct handshakes in the future will > probably create that last issue I mentioned. Now, since it is executed > at a safepoint, with your workaround in enter_interp_only_mode() we > avoid those nested issues in . Maybe 8239084 would have to be revisited > to address nested operations in all cases. It is not clear to me now > though if we should handle that in the handshake code or the caller of a > certain operation should know it might be called in a nested scenario > and should handle it. Last question: is it ok for the processor of a direct handshake operation to do safepoint/handshake checks? I wouldn't see a reason, why not. But certainly I would avoid it. > I'll look a bit more at the updated patch but at first glance looks good. Thanks, Richard. -----Original Message----- From: Patricio Chilano Sent: Freitag, 24. April 2020 19:14 To: Reingruber, Richard ; Yasumasa Suenaga ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant Hi Richard, Just jumping into your last question for now.? : ) On 4/24/20 1:08 PM, Reingruber, Richard wrote: > Hi Yasumasa, Patricio, > >>>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>>> Does it help you? I think it gives you to remove workaround. >>> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >>> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. >> Thanks for your information. >> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. >> I will modify and will test it after yours. > Thanks :) > >>> Also my first impression was that it won't be that easy from a synchronization point of view to >>> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >>> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >>> to me, how this has to be handled. >> I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. > Yes. To me it is unclear what synchronization is necessary, if it is called during a handshake. And > also I'm unsure if a thread should do safepoint checks while executing a handshake. > > @Patricio, coming back to my question [1]: > > In the example you gave in your answer [2]: the java thread would execute a vm operation during a > direct handshake operation, while the VMThread is actually in the middle of a VM_HandshakeAllThreads > operation, waiting to handshake the same handshakee: why can't the VMThread just proceed? The > handshakee would be safepoint safe, wouldn't it? Because the VMThread would not be able to decrement _processing_sem to claim the operation and execute the closure for that handshakee. If another JavaThread is doing a direct handshake with that same handshakee and called a new VM operation inside the execution of the HandshakeClosure in do_handshake(), nobody would be able to decrement the _processing_sem anymore until the original direct operation finished and the semaphore is signaled again. So this can happen despite the state of the handshakee is "handshake/safepoint safe". Changing the nested VM operation to be a direct handshake would have the same issue. Actually as the code is right now we would not even get pass setting the handshake operation because in that case we would block in the _handshake_turn_sem for the same reason. So changing VM_SetFramePop to use direct handshakes in the future will probably create that last issue I mentioned. Now, since it is executed at a safepoint, with your workaround in enter_interp_only_mode() we avoid those nested issues in . Maybe 8239084 would have to be revisited to address nested operations in all cases. It is not clear to me now though if we should handle that in the handshake code or the caller of a certain operation should know it might be called in a nested scenario and should handle it. I'll look a bit more at the updated patch but at first glance looks good. Thanks! Patricio > Thanks, Richard. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301677&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301677 > > [2] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301763&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301763 > > -----Original Message----- > From: Yasumasa Suenaga > Sent: Freitag, 24. April 2020 17:23 > To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Richard, > > On 2020/04/24 23:44, Reingruber, Richard wrote: >> Hi Yasumasa, >> >>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>> Does it help you? I think it gives you to remove workaround. >> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. > Thanks for your information. > I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. > I will modify and will test it after yours. > > >> Also my first impression was that it won't be that easy from a synchronization point of view to >> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >> to me, how this has to be handled. > I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. > > > Thanks, > > Yasumasa > > >> So it appears to me that it would be easier to push JDK-8242427 after this (JDK-8238585). >> >>> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >> Would be interesting to see how you handled the issues above :) >> >> Thanks, Richard. >> >> [1] See question in comment https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030 >> >> -----Original Message----- >> From: Yasumasa Suenaga >> Sent: Freitag, 24. April 2020 13:34 >> To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Richard, >> >> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >> Does it help you? I think it gives you to remove workaround. >> >> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/24 17:18, Reingruber, Richard wrote: >>> Hi Patricio, Vladimir, and Serguei, >>> >>> now that direct handshakes are available, I've updated the patch to make use of them. >>> >>> In addition I have done some clean-up changes I missed in the first webrev. >>> >>> Finally I have implemented the workaround suggested by Patricio to avoid nesting the handshake >>> into the vm operation VM_SetFramePop [1] >>> >>> Kindly review again: >>> >>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ >>> Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ >>> >>> I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode can be replaced with a >>> direct handshake: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238585 >>> >>> Testing: >>> >>> * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>> >>> * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737 >>> >>> Thanks, >>> Richard. >>> >>> [1] An assertion in Handshake::execute_direct() fails, if called be VMThread, because it is no JavaThread. >>> >>> -----Original Message----- >>> From: hotspot-dev On Behalf Of Reingruber, Richard >>> Sent: Freitag, 14. Februar 2020 19:47 >>> To: Patricio Chilano ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Patricio, >>> >>> > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>> > > handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>> > > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>> > > >>> > > > Alternatively I think you could do something similar to what we do in >>> > > > Deoptimization::deoptimize_all_marked(): >>> > > > >>> > > > EnterInterpOnlyModeClosure hs; >>> > > > if (SafepointSynchronize::is_at_safepoint()) { >>> > > > hs.do_thread(state->get_thread()); >>> > > > } else { >>> > > > Handshake::execute(&hs, state->get_thread()); >>> > > > } >>> > > > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>> > > > HandshakeClosure() constructor) >>> > > >>> > > Maybe this could be used also in the Handshake::execute() methods as general solution? >>> > Right, we could also do that. Avoiding to clear the polling page in >>> > HandshakeState::clear_handshake() should be enough to fix this issue and >>> > execute a handshake inside a safepoint, but adding that "if" statement >>> > in Hanshake::execute() sounds good to avoid all the extra code that we >>> > go through when executing a handshake. I filed 8239084 to make that change. >>> >>> Thanks for taking care of this and creating the RFE. >>> >>> > >>> > > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>> > > > always called in a nested operation or just sometimes. >>> > > >>> > > At least one execution path without vm operation exists: >>> > > >>> > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>> > > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>> > > JvmtiEventControllerPrivate::recompute_enabled() : void >>> > > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>> > > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>> > > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>> > > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>> > > >>> > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>> > > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>> > > encouraged to do it with a handshake :) >>> > Ah! I think you can still do it with a handshake with the >>> > Deoptimization::deoptimize_all_marked() like solution. I can change the >>> > if-else statement with just the Handshake::execute() call in 8239084. >>> > But up to you. : ) >>> >>> Well, I think that's enough encouragement :) >>> I'll wait for 8239084 and try then again. >>> (no urgency and all) >>> >>> Thanks, >>> Richard. >>> >>> -----Original Message----- >>> From: Patricio Chilano >>> Sent: Freitag, 14. Februar 2020 15:54 >>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Richard, >>> >>> On 2/14/20 9:58 AM, Reingruber, Richard wrote: >>>> Hi Patricio, >>>> >>>> thanks for having a look. >>>> >>>> > I?m only commenting on the handshake changes. >>>> > I see that operation VM_EnterInterpOnlyMode can be called inside >>>> > operation VM_SetFramePop which also allows nested operations. Here is a >>>> > comment in VM_SetFramePop definition: >>>> > >>>> > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>> > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>> > >>>> > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>> > could have a handshake inside a safepoint operation. The issue I see >>>> > there is that at the end of the handshake the polling page of the target >>>> > thread could be disarmed. So if the target thread happens to be in a >>>> > blocked state just transiently and wakes up then it will not stop for >>>> > the ongoing safepoint. Maybe I can file an RFE to assert that the >>>> > polling page is armed at the beginning of disarm_safepoint(). >>>> >>>> I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>>> handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>>> Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>>> >>>> > Alternatively I think you could do something similar to what we do in >>>> > Deoptimization::deoptimize_all_marked(): >>>> > >>>> > EnterInterpOnlyModeClosure hs; >>>> > if (SafepointSynchronize::is_at_safepoint()) { >>>> > hs.do_thread(state->get_thread()); >>>> > } else { >>>> > Handshake::execute(&hs, state->get_thread()); >>>> > } >>>> > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>> > HandshakeClosure() constructor) >>>> >>>> Maybe this could be used also in the Handshake::execute() methods as general solution? >>> Right, we could also do that. Avoiding to clear the polling page in >>> HandshakeState::clear_handshake() should be enough to fix this issue and >>> execute a handshake inside a safepoint, but adding that "if" statement >>> in Hanshake::execute() sounds good to avoid all the extra code that we >>> go through when executing a handshake. I filed 8239084 to make that change. >>> >>>> > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>> > always called in a nested operation or just sometimes. >>>> >>>> At least one execution path without vm operation exists: >>>> >>>> JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>>> JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>>> JvmtiEventControllerPrivate::recompute_enabled() : void >>>> JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>>> JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>>> JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>>> jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>>> >>>> I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>>> handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>>> encouraged to do it with a handshake :) >>> Ah! I think you can still do it with a handshake with the >>> Deoptimization::deoptimize_all_marked() like solution. I can change the >>> if-else statement with just the Handshake::execute() call in 8239084. >>> But up to you.? : ) >>> >>> Thanks, >>> Patricio >>>> Thanks again, >>>> Richard. >>>> >>>> -----Original Message----- >>>> From: Patricio Chilano >>>> Sent: Donnerstag, 13. Februar 2020 18:47 >>>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>>> >>>> Hi Richard, >>>> >>>> I?m only commenting on the handshake changes. >>>> I see that operation VM_EnterInterpOnlyMode can be called inside >>>> operation VM_SetFramePop which also allows nested operations. Here is a >>>> comment in VM_SetFramePop definition: >>>> >>>> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>> >>>> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>> could have a handshake inside a safepoint operation. The issue I see >>>> there is that at the end of the handshake the polling page of the target >>>> thread could be disarmed. So if the target thread happens to be in a >>>> blocked state just transiently and wakes up then it will not stop for >>>> the ongoing safepoint. Maybe I can file an RFE to assert that the >>>> polling page is armed at the beginning of disarm_safepoint(). >>>> >>>> I think one option could be to remove >>>> SafepointMechanism::disarm_if_needed() in >>>> HandshakeState::clear_handshake() and let each JavaThread disarm itself >>>> for the handshake case. >>>> >>>> Alternatively I think you could do something similar to what we do in >>>> Deoptimization::deoptimize_all_marked(): >>>> >>>> ? EnterInterpOnlyModeClosure hs; >>>> ? if (SafepointSynchronize::is_at_safepoint()) { >>>> ??? hs.do_thread(state->get_thread()); >>>> ? } else { >>>> ??? Handshake::execute(&hs, state->get_thread()); >>>> ? } >>>> (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>> HandshakeClosure() constructor) >>>> >>>> I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>> always called in a nested operation or just sometimes. >>>> >>>> Thanks, >>>> Patricio >>>> >>>> On 2/12/20 7:23 AM, Reingruber, Richard wrote: >>>>> // Repost including hotspot runtime and gc lists. >>>>> // Dean Long suggested to do so, because the enhancement replaces a vm operation >>>>> // with a handshake. >>>>> // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html >>>>> >>>>> Hi, >>>>> >>>>> could I please get reviews for this small enhancement in hotspot's jvmti implementation: >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >>>>> >>>>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to >>>>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. >>>>> >>>>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. >>>>> >>>>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>>>> >>>>> Thanks, Richard. >>>>> >>>>> See also my question if anyone knows a reason for making the compiled methods not_entrant: >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html From leonid.mesnik at oracle.com Fri Apr 24 22:11:20 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 24 Apr 2020 15:11:20 -0700 Subject: RFR (S): 8242237: Improve JVM TI HiddenClasses tests In-Reply-To: <84d00dbf-a6e4-3407-6f8e-f3faa4c92e5c@oracle.com> References: <84d00dbf-a6e4-3407-6f8e-f3faa4c92e5c@oracle.com> Message-ID: Looks good. The small nit (optional). New function 287 static void JNICALL 288 ClassPrepare(jvmtiEnv* jvmti, JNIEnv* jni, jthread thread, jclass klass) { is very similar to ClassLoad, and verification of signature might be moved into common function. Leonid > On Apr 24, 2020, at 11:31 AM, serguei.spitsyn at oracle.com wrote: > > Please, review a fix for the sub-task: > https://bugs.openjdk.java.net/browse/JDK-8242237 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/jvmti-hidden-test-update.1/ > > Summary: > The test update includes: > - interface and method renaming: Test => HCInterf, test() => hcMethod() > - readClassFile replaced with Files.readAllBytes > - added ClassPrepare event > - removed unneeded capability can_get_source_file_name > - added more comments > > Testing: > Tested locally on Linux, mach5 test run is in progress: > https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jvmti-test-20200424-1829-10485216 > > Thanks, > Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Apr 24 22:17:35 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 24 Apr 2020 15:17:35 -0700 Subject: RFR: JDK-8242522: Minor LingeredApp improvements Message-ID: Hi all, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8242522 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev/ The fix contains minor fixes/improvements for LingeredApp and tests which use it. See jira for details. Tested all tests which use LingeredApp. --alex From serguei.spitsyn at oracle.com Fri Apr 24 22:20:12 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Apr 2020 15:20:12 -0700 Subject: RFR (S): 8242237: Improve JVM TI HiddenClasses tests In-Reply-To: References: <84d00dbf-a6e4-3407-6f8e-f3faa4c92e5c@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Apr 24 22:22:24 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Apr 2020 15:22:24 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> References: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Fri Apr 24 22:30:54 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 24 Apr 2020 15:30:54 -0700 Subject: RFR(S/T) : 8243568 : serviceability/logging/TestLogRotation.java uses 'test.java.opts' and not 'test.vm.opts' Message-ID: <5C0211CA-0541-4739-B6E4-00A7DA7A22FF@oracle.com> http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 > 8 lines changed: 0 ins; 6 del; 2 mod; Hi all, could you please review this small and trivial patch which updates serviceability/logging/TestLogRotation.java test to pass both 'test.java.opts' and not 'test.vm.opts' ? to do that, the patch removes the custom logic of handling test.java.opts and just uses ProcessTools.createJavaProcessBuilder(boolean addTestVmAndJavaOptions=true, String...), which prepends values of both properties. from JBS: > serviceability/logging/TestLogRotation.java test use 'test.java.opts' to get external vm flags, yet actually external flags are split b/w 'test.java.opts' and 'test.vm.opts' and in the majority of cases all external flags are set listed in 'test.vm.opts' so the test should be updated to read both. JBS: https://bugs.openjdk.java.net/browse/JDK-8243568 webrev: http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 Thanks, -- Igor From leonid.mesnik at oracle.com Fri Apr 24 22:41:30 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 24 Apr 2020 15:41:30 -0700 Subject: RFR: JDK-8242522: Minor LingeredApp improvements In-Reply-To: References: Message-ID: Looks good. (Not a 'R'eview though.) Leonid. > On Apr 24, 2020, at 3:17 PM, Alex Menkov wrote: > > Hi all, > > Please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8242522 > webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev/ > > The fix contains minor fixes/improvements for LingeredApp and tests which use it. See jira for details. > > Tested all tests which use LingeredApp. > > --alex From chris.plummer at oracle.com Fri Apr 24 22:42:38 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 24 Apr 2020 15:42:38 -0700 Subject: RFR: JDK-8242522: Minor LingeredApp improvements In-Reply-To: References: Message-ID: <619494c6-4b0e-1c38-d9e4-2e57a511377a@oracle.com> Hi Alex, Overall it looks good, although I'm not so sure I agree with removing getAppOutput(). It's a generally useful utility API. Seems it is better off in LingeredApp.java rather than in the one test that currently uses it. thanks, Chris On 4/24/20 3:17 PM, Alex Menkov wrote: > Hi all, > > Please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8242522 > webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev/ > > The fix contains minor fixes/improvements for LingeredApp and tests > which use it. See jira for details. > > Tested all tests which use LingeredApp. > > --alex From leonid.mesnik at oracle.com Fri Apr 24 22:41:48 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 24 Apr 2020 15:41:48 -0700 Subject: RFR(S/T) : 8243568 : serviceability/logging/TestLogRotation.java uses 'test.java.opts' and not 'test.vm.opts' In-Reply-To: <5C0211CA-0541-4739-B6E4-00A7DA7A22FF@oracle.com> References: <5C0211CA-0541-4739-B6E4-00A7DA7A22FF@oracle.com> Message-ID: <5CF31E65-6E7E-4327-9549-7BF828A72963@oracle.com> Looks good. (Need a 'R'eview.) Leonid. > On Apr 24, 2020, at 3:30 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 >> 8 lines changed: 0 ins; 6 del; 2 mod; > > Hi all, > > could you please review this small and trivial patch which updates serviceability/logging/TestLogRotation.java test to pass both 'test.java.opts' and not 'test.vm.opts' ? to do that, the patch removes the custom logic of handling test.java.opts and just uses ProcessTools.createJavaProcessBuilder(boolean addTestVmAndJavaOptions=true, String...), which prepends values of both properties. > from JBS: >> serviceability/logging/TestLogRotation.java test use 'test.java.opts' to get external vm flags, yet actually external flags are split b/w 'test.java.opts' and 'test.vm.opts' and in the majority of cases all external flags are set listed in 'test.vm.opts' so the test should be updated to read both. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8243568 > webrev: http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 > > Thanks, > -- Igor From chris.plummer at oracle.com Fri Apr 24 22:53:24 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 24 Apr 2020 15:53:24 -0700 Subject: RFR(S/T) : 8243568 : serviceability/logging/TestLogRotation.java uses 'test.java.opts' and not 'test.vm.opts' In-Reply-To: <5CF31E65-6E7E-4327-9549-7BF828A72963@oracle.com> References: <5C0211CA-0541-4739-B6E4-00A7DA7A22FF@oracle.com> <5CF31E65-6E7E-4327-9549-7BF828A72963@oracle.com> Message-ID: Adding hotspot-runtime-dev since logging is owned by runtime, not serviceability. Chris On 4/24/20 3:41 PM, Leonid Mesnik wrote: > Looks good. (Need a 'R'eview.) > > Leonid. > >> On Apr 24, 2020, at 3:30 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 >>> 8 lines changed: 0 ins; 6 del; 2 mod; >> Hi all, >> >> could you please review this small and trivial patch which updates serviceability/logging/TestLogRotation.java test to pass both 'test.java.opts' and not 'test.vm.opts' ? to do that, the patch removes the custom logic of handling test.java.opts and just uses ProcessTools.createJavaProcessBuilder(boolean addTestVmAndJavaOptions=true, String...), which prepends values of both properties. >> from JBS: >>> serviceability/logging/TestLogRotation.java test use 'test.java.opts' to get external vm flags, yet actually external flags are split b/w 'test.java.opts' and 'test.vm.opts' and in the majority of cases all external flags are set listed in 'test.vm.opts' so the test should be updated to read both. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8243568 >> webrev: http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 >> >> Thanks, >> -- Igor From alexey.menkov at oracle.com Sat Apr 25 01:52:57 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 24 Apr 2020 18:52:57 -0700 Subject: RFR: JDK-8242522: Minor LingeredApp improvements In-Reply-To: <619494c6-4b0e-1c38-d9e4-2e57a511377a@oracle.com> References: <619494c6-4b0e-1c38-d9e4-2e57a511377a@oracle.com> Message-ID: <8341e8f7-8944-1dfd-6891-1846082fa5fe@oracle.com> Hi Chris, On 04/24/2020 15:42, Chris Plummer wrote: > Hi Alex, > > Overall it looks good, although I'm not so sure I agree with removing > getAppOutput(). It's a generally useful utility API. Seems it is better > off in LingeredApp.java rather than in the one test that currently uses it. To me the method just adds noise to the class. If you think it can be useful for some other tests, I'd move it to to OutputBuffer (make it default method which uses OutputBuffer.getStdout()): default public List getStdOutAsList() --alex > > thanks, > > Chris > > On 4/24/20 3:17 PM, Alex Menkov wrote: >> Hi all, >> >> Please review the fix for >> https://bugs.openjdk.java.net/browse/JDK-8242522 >> webrev: >> http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev/ >> >> The fix contains minor fixes/improvements for LingeredApp and tests >> which use it. See jira for details. >> >> Tested all tests which use LingeredApp. >> >> --alex > From chris.plummer at oracle.com Sat Apr 25 03:38:34 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 24 Apr 2020 20:38:34 -0700 Subject: RFR: JDK-8242522: Minor LingeredApp improvements In-Reply-To: <8341e8f7-8944-1dfd-6891-1846082fa5fe@oracle.com> References: <619494c6-4b0e-1c38-d9e4-2e57a511377a@oracle.com> <8341e8f7-8944-1dfd-6891-1846082fa5fe@oracle.com> Message-ID: On 4/24/20 6:52 PM, Alex Menkov wrote: > Hi Chris, > > On 04/24/2020 15:42, Chris Plummer wrote: >> Hi Alex, >> >> Overall it looks good, although I'm not so sure I agree with removing >> getAppOutput(). It's a generally useful utility API. Seems it is >> better off in LingeredApp.java rather than in the one test that >> currently uses it. > > To me the method just adds noise to the class. > If you think it can be useful for some other tests, I'd move it to to > OutputBuffer (make it default method which uses > OutputBuffer.getStdout()): > > default public List getStdOutAsList() I think that's a good idea. It looks like what tests are commonly doing now is using String.split(): ??????????? String[] appLines?? = app.getOutput().getStdout().split("\\R"); I'm not sure of the pros and cons of producing a String[] this way vs a List using getStdOutAsList(). Maybe both have their uses. But one thing for sure is the split() code is a lot more readable. One reason I prefer getStdOutAsList() being placed in a library or utility class is because TBH I find Streams code very hard to read, and combining with chained Reader code doesn't help any, so I just assume it be in a library that I'm less apt to look at rather than in the test where I'm bound to find my eyes glazing over as I'm drawn in to figure it out. Chris > > --alex > >> >> thanks, >> >> Chris >> >> On 4/24/20 3:17 PM, Alex Menkov wrote: >>> Hi all, >>> >>> Please review the fix for >>> https://bugs.openjdk.java.net/browse/JDK-8242522 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev/ >>> >>> The fix contains minor fixes/improvements for LingeredApp and tests >>> which use it. See jira for details. >>> >>> Tested all tests which use LingeredApp. >>> >>> --alex >> From daniil.x.titov at oracle.com Sat Apr 25 05:22:40 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 24 Apr 2020 22:22:40 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same In-Reply-To: References: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> <9deb907b-0cbb-2a05-73a3-1aa4c6f5fc94@oracle.com> <9523cda9-66a0-e609-f199-117f02d907d7@oracle.com> Message-ID: <1F96342D-332B-4ABE-9BCC-952969421805@oracle.com> Hi Chris and Serguei, Please review a new version of the fix [1] that makes the tests try to repeat the check only once. Regarding the question Serguei asked: > 97 while(true) { > 113 if (mbeanCount * 2 == counterCount || isSecondAttempt) { > 114 assertEquals(mbeanCount * 2, counterCount); > I doubt, the assert is really needed. we need the assert here to make the test fail in case if it is a second attempt and the conditions are not met. [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.02/ [2] https://bugs.openjdk.java.net/browse/JDK-8242239 Thank you, Daniil From: serviceability-dev on behalf of Daniil Titov Date: Friday, April 24, 2020 at 2:08 PM To: Chris Plummer , "serguei.spitsyn at oracle.com" , serviceability-dev Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same Hi Chris, ? I agree with you. I will change the test to retry just once. ? Thank you, Daniil ? ? From: Chris Plummer Date: Friday, April 24, 2020 at 1:27 PM To: Daniil Titov , "serguei.spitsyn at oracle.com" , serviceability-dev Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same ? Hi Daniil, I think a retry count more in line with our current expectations would make more sense since it is deterministic how many retries are might actually be needed. You just used a large number in case more ?lazy-registered? mbeans are added in the future, but if this is the case then maybe even 10 is not enough. thanks, Chris On 4/24/20 12:36 PM, Daniil Titov wrote: Hi Serguei and Chris, ? Thank you for your comments. ? I wanted to make the fix ?more generic ?and not limit it just to Graal management bean. In this case we could expect that after the first retry is triggered by Graal MBean registration some other ?lazy-registered? MBean got registered and the test might fail. To avoid this we need to allow test to make at least several retry attempts before failing.? If number 10 looks as too high we could make it 5 or even 3. This should not affect the test run-time unless the test starts failing for some other reason than we expect. ?In the new webrev I will also correct ?the iteration counting (as Chris mentioned) and fix typos. ? Thanks again, Daniil ? From: mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com Date: Friday, April 24, 2020 at 11:48 AM To: Chris Plummer mailto:chris.plummer at oracle.com, Daniil Titov mailto:daniil.x.titov at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same ? Hi Daniil, Besides what Chris is pointed out the fix looks good. Minor: ? 97???????? while(true) { 113???????????? if(mbeanCount * 2 == counterCount || retryCounter++ > MAX_RETRY_ATTEMPT) { 114???????????????? assertEquals(mbeanCount * 2, counterCount); ?Space is missed in while and if. ?I doubt, the assert is really needed. ? 96???????? // is running ( e.g. Graal MBean). In this case just retry the test. ?Extra space before "e.g.". Thanks, Serguei On 4/24/20 11:30, Chris Plummer wrote: Hi Daniil, ? 84???????????? // If new MBean (e.g. Graal MBean) is registred while the test is running names1, ?106???????????? // If new MBean (e.g. Graal MBean) is registred while the test is running mbeans1, registred -> registered ',' after "running" Just wondering how you chose 10 as the number of retries. Seems excessive. Shouldn't the problem turn up at most 1 time and therefore only 1 retry is needed. ? 76???????? int counter = 0; ? 86???????????? if (sameSize(names1, names2, names3) || counter++ > MAX_RETRY_ATTEMPTS) { The way the checks are done you will actually end up retrying MAX_RETRY_ATTEMPTS+1 times. For example, if MAX_RETRY_ATTEMPTS is 1, first time through the loop counter is 0 so a retry is allowed. Second time through the loop counter is 1, so a retry is allowed again. thanks, Chris On 4/18/20 11:30 AM, Daniil Titov wrote: Please review the change that fixes the failure of javax/management/generified/GenericTest.java? and ? javax/management/query/CustomQueryTest.java tests when Graal is on. The tests checks that calls of management API are consistent and return the same set of MBeans.? However, when Graal is on the Graal MBean might be registered between the calls that in turn makes the results inconsistent and the tests fail. The fix makes the test aware that some MBean might be registered while the checks run and if it happens the tests repeat the check. Testing : Mach5 tests with Graal on and tier1-tier3 tests passed. [1]? http://cr.openjdk.java.net/~dtitov/8242239/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8242239 Thanks, Daniil ? From daniil.x.titov at oracle.com Sat Apr 25 05:44:01 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 24 Apr 2020 22:44:01 -0700 Subject: RFR: 8238561 serviceability/sa tests continue to run out of memory on Win* machines In-Reply-To: References: <8BFDF542-F950-472D-8EB4-DE32090C4A43@oracle.com> Message-ID: <02B6068B-6785-4C60-A275-48E7524E4AB2@oracle.com> Hi Leonid, I run the test with -XComp at Mach5 linux-x64-debug builds before and after the changes the forwards VM and test options to j-* tools and here is the difference in the execution times for some serviceability/sa tests: serviceability/sa/sadebugd/SADebugDTest.java, before : 2m 23s , after:11m 07s serviceability/sa/sadebugd/TestJmapCore.java, before : 42s , after:1m 09s serviceability/sa/TestSysProps.java, before : 36s , after:1m 27s Thus for the most of the tests the overhead is about 2 times although in case of serviceability/sa/sadebugd/SADebugDTest.java it spikes up to 5 times. Best regards, Daniil ?On 4/23/20, 11:23 AM, "Leonid Mesnik" wrote: Hi Daniil Have you checked how longer tests are executed with adding java options to launchers (with Xcomp/Graal/ZGC)? If the overhead is not significant might be it make worth to add options by default? The idea is to add vm.opts to all processes and java.opts to tested only. But if you believe that adding java.opts to jdk tools helps to improve testing then it is better just to add it by default. It helps to avoid similar failures in the future or with highly concurrent execution (when tens of jaotc are started for example). Leonid On 4/23/20 11:10 AM, Chris Plummer wrote: > On 4/23/20 10:18 AM, Daniil Titov wrote: >> Hi Chris, >> >> I will revoke this RFR and resubmit it under JDK-8242009 >> with the changes you suggested to use Utils.getTestJavaOpts() >> and make JDKToolLauncher to have an option to forward VM options. >> > It could also be done with a new API such as > JDKToolLauncher.addVMArgs(). That might be better than a new "create" > API. > > thank,s > > Chris >>> Is your change causing -Xshowversion to be passed? >> Yes, the changes makes tests run with -Xshowversion to be passed. >> >>> Do you know where it is coming from? >> It is coming from task definitions for different tiers. >> >> Thank you, >> Daniil >> >> ?On 4/22/20, 12:54 PM, "Chris Plummer" wrote: >> >> Hi Daniil, >> >> Thanks for cleaning this up. I think this should be fixed under >> JDK-8242009. JDK-8238561 involves more than just this one issue. >> >> Is there a reason why you didn't just change JDKToolLauncher to >> have an >> option or API to add the args? >> >> Why are you calling Utils.addTestJavaOpts() instead of >> Utils.getTestJavaOpts()? >> >> Is your change causing -Xshowversion to be passed? Do you know >> where it >> is coming from? >> >> thanks, >> >> Chris >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8242009 >> >> On 4/22/20 10:48 AM, Daniil Titov wrote: >> > Please review the change [1] that ensures that VM and test >> options are forwarded to >> > j*-tools when they are launched from serviceability/sa tests. >> > >> > In particular, it will ensure that passed to the tests maximum >> heap size settings ( -XX:MaxRAMPercentage) >> > are also honored by j*-tools serviceability/sa tests launch. >> > >> > The tests that expect an empty output were corrected to >> ignore the product version printed >> > in the error stream since in some tiers the tests are run >> with ' -showversion' VM option. >> > >> > Testing: Mach5 tests for tier1 - tier7 passed. >> > >> > [1] http://cr.openjdk.java.net/~dtitov/8238561/webrev.01 >> > [2] https://bugs.openjdk.java.net/browse/JDK-8238561 >> > >> > Thank you, >> > Daniil >> > >> > >> >> >> > > From serguei.spitsyn at oracle.com Sat Apr 25 07:06:27 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 25 Apr 2020 00:06:27 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same In-Reply-To: <1F96342D-332B-4ABE-9BCC-952969421805@oracle.com> References: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> <9deb907b-0cbb-2a05-73a3-1aa4c6f5fc94@oracle.com> <9523cda9-66a0-e609-f199-117f02d907d7@oracle.com> <1F96342D-332B-4ABE-9BCC-952969421805@oracle.com> Message-ID: <0df530e0-0ef7-10cd-7226-c6ebbca7654f@oracle.com> An HTML attachment was scrubbed... URL: From patricio.chilano.mateo at oracle.com Sat Apr 25 09:23:03 2020 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Sat, 25 Apr 2020 06:23:03 -0300 Subject: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant In-Reply-To: References: <3c59b9f9-ec38-18c9-8f24-e1186a08a04a@oracle.com> <410eed04-e2ef-0f4f-1c56-19e6734a10f6@oracle.com> <81d7caa8-4244-85f3-4d4e-78117fe5e25b@oss.nttdata.com> <11c78b30-de04-544d-3a10-811ebf663bf2@oracle.com> Message-ID: <7bb8abdc-6c49-3059-23d5-9552bd80b480@oracle.com> Hi Richard, On 4/24/20 6:41 PM, Reingruber, Richard wrote: > Hi Patricio, > >>> @Patricio, coming back to my question [1]: >>> >>> In the example you gave in your answer [2]: the java thread would execute a vm operation during a >>> direct handshake operation, while the VMThread is actually in the middle of a VM_HandshakeAllThreads >>> operation, waiting to handshake the same handshakee: why can't the VMThread just proceed? The >>> handshakee would be safepoint safe, wouldn't it? >> Because the VMThread would not be able to decrement _processing_sem to >> claim the operation and execute the closure for that handshakee. If >> another JavaThread is doing a direct handshake with that same handshakee >> and called a new VM operation inside the execution of the >> HandshakeClosure in do_handshake(), nobody would be able to decrement >> the _processing_sem anymore until the original direct operation finished >> and the semaphore is signaled again. > Thanks, understood. On a higher level: a JavaThread can have at most one handshake operation being > processed at at time. Exactly. As of now we don't handle the case where another handshake operation on the same handshakee is called inside _handshake_cl->do_thread(). If this happens we will deadlock. >> So this can happen despite the >> state of the handshakee is "handshake/safepoint safe". Changing the >> nested VM operation to be a direct handshake would have the same issue. >> Actually as the code is right now we would not even get pass setting the >> handshake operation because in that case we would block in the >> _handshake_turn_sem for the same reason. > Don't really understand the details here, but that's ok. > Interesting that _handshake_turn_sem gets signaled before or after do_handshake() depending if the > handshake operation is processed by handshakee. Comments say "Disarm before/after executing > operation" but not why :) Yes, that pattern actually relates with clearing _operation and predates direct handshakes. In theory we should always call do_handshake() first and then clear the handshake. This is what we do when the operation is processed by the handshaker, and it is necessary to be that way, otherwise if we clear the handshake first then the handshakee might transition from the safe state and never see that it actually has to stop for the handshake. Now, when the handshake operation is processed by the handshakee itself we don't have that issue, so it doesn't matter if we clear it before or after. The reason we do it before is to avoid the VMThread to execute unnecessary instructions in try_process(). This is specially true for the VM_HandshakeAllThreads operation case. If the VMThread sees that a JavaThread doesn't have an operation set, it can just continue to try to process the next JavaThread, instead of going through the unnecessary steps of checking the state of the JavaThread and trying to execute a try_wait() operation on the _processing_sem which we know won't succeed. Now for the direct handshake case doing it before or after doesn't really matter and so I just copied the pattern from the non-direct case to make it consistent in that same method. >> So changing VM_SetFramePop to use direct handshakes in the future will >> probably create that last issue I mentioned. Now, since it is executed >> at a safepoint, with your workaround in enter_interp_only_mode() we >> avoid those nested issues in . Maybe 8239084 would have to be revisited >> to address nested operations in all cases. It is not clear to me now >> though if we should handle that in the handshake code or the caller of a >> certain operation should know it might be called in a nested scenario >> and should handle it. > Last question: is it ok for the processor of a direct handshake operation to do safepoint/handshake > checks? I wouldn't see a reason, why not. But certainly I would avoid it. I tried to think of possible issues with that (independent of the closure logic) but I couldn't find a specific one. If the handshakee tries to process a pending handshake, process_by_self() will just return without calling process_self_inner() since it will detect it is already inside a handshake. And that behaviour makes sense since there is no point in trying to execute a new handshake operation if you are in the middle of another one. If the handshaker inside the closure checks for its own pending handshakes that also seems okay (this will by itself also check for safepoints in the transitions). Checking for safepoints in both cases seems more tricky but I couldn't think of a concrete issue with that. In any case I would also avoid checking for safepoints/handshakes inside the handshake closure. You might get issues related to the actual logic of the closure, like the typical deadlock because of trying to grab the same lock (although it's true that you always have to deal with that kind of problems when checking for safepoint/handshakes), or coming back from the safepoint/handshake and failing because some state you didn't expect to change in the middle of the handshake actually changed. Thanks, Patricio >> I'll look a bit more at the updated patch but at first glance looks good. > Thanks, > Richard. > > -----Original Message----- > From: Patricio Chilano > Sent: Freitag, 24. April 2020 19:14 > To: Reingruber, Richard ; Yasumasa Suenaga ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Richard, > > Just jumping into your last question for now.? : ) > > > On 4/24/20 1:08 PM, Reingruber, Richard wrote: >> Hi Yasumasa, Patricio, >> >>>>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>>>> Does it help you? I think it gives you to remove workaround. >>>> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >>>> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >>>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. >>> Thanks for your information. >>> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. >>> I will modify and will test it after yours. >> Thanks :) >> >>>> Also my first impression was that it won't be that easy from a synchronization point of view to >>>> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >>>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >>>> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >>>> to me, how this has to be handled. >>> I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. >> Yes. To me it is unclear what synchronization is necessary, if it is called during a handshake. And >> also I'm unsure if a thread should do safepoint checks while executing a handshake. >> >> @Patricio, coming back to my question [1]: >> >> In the example you gave in your answer [2]: the java thread would execute a vm operation during a >> direct handshake operation, while the VMThread is actually in the middle of a VM_HandshakeAllThreads >> operation, waiting to handshake the same handshakee: why can't the VMThread just proceed? The >> handshakee would be safepoint safe, wouldn't it? > Because the VMThread would not be able to decrement _processing_sem to > claim the operation and execute the closure for that handshakee. If > another JavaThread is doing a direct handshake with that same handshakee > and called a new VM operation inside the execution of the > HandshakeClosure in do_handshake(), nobody would be able to decrement > the _processing_sem anymore until the original direct operation finished > and the semaphore is signaled again. So this can happen despite the > state of the handshakee is "handshake/safepoint safe". Changing the > nested VM operation to be a direct handshake would have the same issue. > Actually as the code is right now we would not even get pass setting the > handshake operation because in that case we would block in the > _handshake_turn_sem for the same reason. > > So changing VM_SetFramePop to use direct handshakes in the future will > probably create that last issue I mentioned. Now, since it is executed > at a safepoint, with your workaround in enter_interp_only_mode() we > avoid those nested issues in . Maybe 8239084 would have to be revisited > to address nested operations in all cases. It is not clear to me now > though if we should handle that in the handshake code or the caller of a > certain operation should know it might be called in a nested scenario > and should handle it. > > I'll look a bit more at the updated patch but at first glance looks good. > > Thanks! > > Patricio >> Thanks, Richard. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301677&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301677 >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301763&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301763 >> >> -----Original Message----- >> From: Yasumasa Suenaga >> Sent: Freitag, 24. April 2020 17:23 >> To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Richard, >> >> On 2020/04/24 23:44, Reingruber, Richard wrote: >>> Hi Yasumasa, >>> >>>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>>> Does it help you? I think it gives you to remove workaround. >>> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >>> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. >> Thanks for your information. >> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. >> I will modify and will test it after yours. >> >> >>> Also my first impression was that it won't be that easy from a synchronization point of view to >>> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >>> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >>> to me, how this has to be handled. >> I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. >> >> >> Thanks, >> >> Yasumasa >> >> >>> So it appears to me that it would be easier to push JDK-8242427 after this (JDK-8238585). >>> >>>> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >>> Would be interesting to see how you handled the issues above :) >>> >>> Thanks, Richard. >>> >>> [1] See question in comment https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030 >>> >>> -----Original Message----- >>> From: Yasumasa Suenaga >>> Sent: Freitag, 24. April 2020 13:34 >>> To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Richard, >>> >>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>> Does it help you? I think it gives you to remove workaround. >>> >>> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/04/24 17:18, Reingruber, Richard wrote: >>>> Hi Patricio, Vladimir, and Serguei, >>>> >>>> now that direct handshakes are available, I've updated the patch to make use of them. >>>> >>>> In addition I have done some clean-up changes I missed in the first webrev. >>>> >>>> Finally I have implemented the workaround suggested by Patricio to avoid nesting the handshake >>>> into the vm operation VM_SetFramePop [1] >>>> >>>> Kindly review again: >>>> >>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ >>>> Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ >>>> >>>> I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode can be replaced with a >>>> direct handshake: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238585 >>>> >>>> Testing: >>>> >>>> * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>>> >>>> * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737 >>>> >>>> Thanks, >>>> Richard. >>>> >>>> [1] An assertion in Handshake::execute_direct() fails, if called be VMThread, because it is no JavaThread. >>>> >>>> -----Original Message----- >>>> From: hotspot-dev On Behalf Of Reingruber, Richard >>>> Sent: Freitag, 14. Februar 2020 19:47 >>>> To: Patricio Chilano ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>>> Subject: RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>>> >>>> Hi Patricio, >>>> >>>> > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>>> > > handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>>> > > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>>> > > >>>> > > > Alternatively I think you could do something similar to what we do in >>>> > > > Deoptimization::deoptimize_all_marked(): >>>> > > > >>>> > > > EnterInterpOnlyModeClosure hs; >>>> > > > if (SafepointSynchronize::is_at_safepoint()) { >>>> > > > hs.do_thread(state->get_thread()); >>>> > > > } else { >>>> > > > Handshake::execute(&hs, state->get_thread()); >>>> > > > } >>>> > > > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>> > > > HandshakeClosure() constructor) >>>> > > >>>> > > Maybe this could be used also in the Handshake::execute() methods as general solution? >>>> > Right, we could also do that. Avoiding to clear the polling page in >>>> > HandshakeState::clear_handshake() should be enough to fix this issue and >>>> > execute a handshake inside a safepoint, but adding that "if" statement >>>> > in Hanshake::execute() sounds good to avoid all the extra code that we >>>> > go through when executing a handshake. I filed 8239084 to make that change. >>>> >>>> Thanks for taking care of this and creating the RFE. >>>> >>>> > >>>> > > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>> > > > always called in a nested operation or just sometimes. >>>> > > >>>> > > At least one execution path without vm operation exists: >>>> > > >>>> > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>>> > > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>>> > > JvmtiEventControllerPrivate::recompute_enabled() : void >>>> > > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>>> > > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>>> > > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>>> > > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>>> > > >>>> > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>>> > > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>>> > > encouraged to do it with a handshake :) >>>> > Ah! I think you can still do it with a handshake with the >>>> > Deoptimization::deoptimize_all_marked() like solution. I can change the >>>> > if-else statement with just the Handshake::execute() call in 8239084. >>>> > But up to you. : ) >>>> >>>> Well, I think that's enough encouragement :) >>>> I'll wait for 8239084 and try then again. >>>> (no urgency and all) >>>> >>>> Thanks, >>>> Richard. >>>> >>>> -----Original Message----- >>>> From: Patricio Chilano >>>> Sent: Freitag, 14. Februar 2020 15:54 >>>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>>> >>>> Hi Richard, >>>> >>>> On 2/14/20 9:58 AM, Reingruber, Richard wrote: >>>>> Hi Patricio, >>>>> >>>>> thanks for having a look. >>>>> >>>>> > I?m only commenting on the handshake changes. >>>>> > I see that operation VM_EnterInterpOnlyMode can be called inside >>>>> > operation VM_SetFramePop which also allows nested operations. Here is a >>>>> > comment in VM_SetFramePop definition: >>>>> > >>>>> > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>>> > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>>> > >>>>> > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>>> > could have a handshake inside a safepoint operation. The issue I see >>>>> > there is that at the end of the handshake the polling page of the target >>>>> > thread could be disarmed. So if the target thread happens to be in a >>>>> > blocked state just transiently and wakes up then it will not stop for >>>>> > the ongoing safepoint. Maybe I can file an RFE to assert that the >>>>> > polling page is armed at the beginning of disarm_safepoint(). >>>>> >>>>> I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>>>> handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>>>> Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>>>> >>>>> > Alternatively I think you could do something similar to what we do in >>>>> > Deoptimization::deoptimize_all_marked(): >>>>> > >>>>> > EnterInterpOnlyModeClosure hs; >>>>> > if (SafepointSynchronize::is_at_safepoint()) { >>>>> > hs.do_thread(state->get_thread()); >>>>> > } else { >>>>> > Handshake::execute(&hs, state->get_thread()); >>>>> > } >>>>> > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>>> > HandshakeClosure() constructor) >>>>> >>>>> Maybe this could be used also in the Handshake::execute() methods as general solution? >>>> Right, we could also do that. Avoiding to clear the polling page in >>>> HandshakeState::clear_handshake() should be enough to fix this issue and >>>> execute a handshake inside a safepoint, but adding that "if" statement >>>> in Hanshake::execute() sounds good to avoid all the extra code that we >>>> go through when executing a handshake. I filed 8239084 to make that change. >>>> >>>>> > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>>> > always called in a nested operation or just sometimes. >>>>> >>>>> At least one execution path without vm operation exists: >>>>> >>>>> JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>>>> JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>>>> JvmtiEventControllerPrivate::recompute_enabled() : void >>>>> JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>>>> JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>>>> JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>>>> jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>>>> >>>>> I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>>>> handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>>>> encouraged to do it with a handshake :) >>>> Ah! I think you can still do it with a handshake with the >>>> Deoptimization::deoptimize_all_marked() like solution. I can change the >>>> if-else statement with just the Handshake::execute() call in 8239084. >>>> But up to you.? : ) >>>> >>>> Thanks, >>>> Patricio >>>>> Thanks again, >>>>> Richard. >>>>> >>>>> -----Original Message----- >>>>> From: Patricio Chilano >>>>> Sent: Donnerstag, 13. Februar 2020 18:47 >>>>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>>>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>>>> >>>>> Hi Richard, >>>>> >>>>> I?m only commenting on the handshake changes. >>>>> I see that operation VM_EnterInterpOnlyMode can be called inside >>>>> operation VM_SetFramePop which also allows nested operations. Here is a >>>>> comment in VM_SetFramePop definition: >>>>> >>>>> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>>> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>>> >>>>> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>>> could have a handshake inside a safepoint operation. The issue I see >>>>> there is that at the end of the handshake the polling page of the target >>>>> thread could be disarmed. So if the target thread happens to be in a >>>>> blocked state just transiently and wakes up then it will not stop for >>>>> the ongoing safepoint. Maybe I can file an RFE to assert that the >>>>> polling page is armed at the beginning of disarm_safepoint(). >>>>> >>>>> I think one option could be to remove >>>>> SafepointMechanism::disarm_if_needed() in >>>>> HandshakeState::clear_handshake() and let each JavaThread disarm itself >>>>> for the handshake case. >>>>> >>>>> Alternatively I think you could do something similar to what we do in >>>>> Deoptimization::deoptimize_all_marked(): >>>>> >>>>> ? EnterInterpOnlyModeClosure hs; >>>>> ? if (SafepointSynchronize::is_at_safepoint()) { >>>>> ??? hs.do_thread(state->get_thread()); >>>>> ? } else { >>>>> ??? Handshake::execute(&hs, state->get_thread()); >>>>> ? } >>>>> (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>>> HandshakeClosure() constructor) >>>>> >>>>> I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>>> always called in a nested operation or just sometimes. >>>>> >>>>> Thanks, >>>>> Patricio >>>>> >>>>> On 2/12/20 7:23 AM, Reingruber, Richard wrote: >>>>>> // Repost including hotspot runtime and gc lists. >>>>>> // Dean Long suggested to do so, because the enhancement replaces a vm operation >>>>>> // with a handshake. >>>>>> // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html >>>>>> >>>>>> Hi, >>>>>> >>>>>> could I please get reviews for this small enhancement in hotspot's jvmti implementation: >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >>>>>> >>>>>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to >>>>>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. >>>>>> >>>>>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. >>>>>> >>>>>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>>>>> >>>>>> Thanks, Richard. >>>>>> >>>>>> See also my question if anyone knows a reason for making the compiled methods not_entrant: >>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html From richard.reingruber at sap.com Sat Apr 25 10:28:00 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Sat, 25 Apr 2020 10:28:00 +0000 Subject: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant In-Reply-To: <7bb8abdc-6c49-3059-23d5-9552bd80b480@oracle.com> References: <3c59b9f9-ec38-18c9-8f24-e1186a08a04a@oracle.com> <410eed04-e2ef-0f4f-1c56-19e6734a10f6@oracle.com> <81d7caa8-4244-85f3-4d4e-78117fe5e25b@oss.nttdata.com> <11c78b30-de04-544d-3a10-811ebf663bf2@oracle.com> <7bb8abdc-6c49-3059-23d5-9552bd80b480@oracle.com> Message-ID: Hi Patricio, thanks a lot for all the explanations. At least to me they are really helpful. :) Cheers, Richard. -----Original Message----- From: Patricio Chilano Sent: Samstag, 25. April 2020 11:23 To: Reingruber, Richard ; Yasumasa Suenaga ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant Hi Richard, On 4/24/20 6:41 PM, Reingruber, Richard wrote: > Hi Patricio, > >>> @Patricio, coming back to my question [1]: >>> >>> In the example you gave in your answer [2]: the java thread would execute a vm operation during a >>> direct handshake operation, while the VMThread is actually in the middle of a VM_HandshakeAllThreads >>> operation, waiting to handshake the same handshakee: why can't the VMThread just proceed? The >>> handshakee would be safepoint safe, wouldn't it? >> Because the VMThread would not be able to decrement _processing_sem to >> claim the operation and execute the closure for that handshakee. If >> another JavaThread is doing a direct handshake with that same handshakee >> and called a new VM operation inside the execution of the >> HandshakeClosure in do_handshake(), nobody would be able to decrement >> the _processing_sem anymore until the original direct operation finished >> and the semaphore is signaled again. > Thanks, understood. On a higher level: a JavaThread can have at most one handshake operation being > processed at at time. Exactly. As of now we don't handle the case where another handshake operation on the same handshakee is called inside _handshake_cl->do_thread(). If this happens we will deadlock. >> So this can happen despite the >> state of the handshakee is "handshake/safepoint safe". Changing the >> nested VM operation to be a direct handshake would have the same issue. >> Actually as the code is right now we would not even get pass setting the >> handshake operation because in that case we would block in the >> _handshake_turn_sem for the same reason. > Don't really understand the details here, but that's ok. > Interesting that _handshake_turn_sem gets signaled before or after do_handshake() depending if the > handshake operation is processed by handshakee. Comments say "Disarm before/after executing > operation" but not why :) Yes, that pattern actually relates with clearing _operation and predates direct handshakes. In theory we should always call do_handshake() first and then clear the handshake. This is what we do when the operation is processed by the handshaker, and it is necessary to be that way, otherwise if we clear the handshake first then the handshakee might transition from the safe state and never see that it actually has to stop for the handshake. Now, when the handshake operation is processed by the handshakee itself we don't have that issue, so it doesn't matter if we clear it before or after. The reason we do it before is to avoid the VMThread to execute unnecessary instructions in try_process(). This is specially true for the VM_HandshakeAllThreads operation case. If the VMThread sees that a JavaThread doesn't have an operation set, it can just continue to try to process the next JavaThread, instead of going through the unnecessary steps of checking the state of the JavaThread and trying to execute a try_wait() operation on the _processing_sem which we know won't succeed. Now for the direct handshake case doing it before or after doesn't really matter and so I just copied the pattern from the non-direct case to make it consistent in that same method. >> So changing VM_SetFramePop to use direct handshakes in the future will >> probably create that last issue I mentioned. Now, since it is executed >> at a safepoint, with your workaround in enter_interp_only_mode() we >> avoid those nested issues in . Maybe 8239084 would have to be revisited >> to address nested operations in all cases. It is not clear to me now >> though if we should handle that in the handshake code or the caller of a >> certain operation should know it might be called in a nested scenario >> and should handle it. > Last question: is it ok for the processor of a direct handshake operation to do safepoint/handshake > checks? I wouldn't see a reason, why not. But certainly I would avoid it. I tried to think of possible issues with that (independent of the closure logic) but I couldn't find a specific one. If the handshakee tries to process a pending handshake, process_by_self() will just return without calling process_self_inner() since it will detect it is already inside a handshake. And that behaviour makes sense since there is no point in trying to execute a new handshake operation if you are in the middle of another one. If the handshaker inside the closure checks for its own pending handshakes that also seems okay (this will by itself also check for safepoints in the transitions). Checking for safepoints in both cases seems more tricky but I couldn't think of a concrete issue with that. In any case I would also avoid checking for safepoints/handshakes inside the handshake closure. You might get issues related to the actual logic of the closure, like the typical deadlock because of trying to grab the same lock (although it's true that you always have to deal with that kind of problems when checking for safepoint/handshakes), or coming back from the safepoint/handshake and failing because some state you didn't expect to change in the middle of the handshake actually changed. Thanks, Patricio >> I'll look a bit more at the updated patch but at first glance looks good. > Thanks, > Richard. > > -----Original Message----- > From: Patricio Chilano > Sent: Freitag, 24. April 2020 19:14 > To: Reingruber, Richard ; Yasumasa Suenaga ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Richard, > > Just jumping into your last question for now.? : ) > > > On 4/24/20 1:08 PM, Reingruber, Richard wrote: >> Hi Yasumasa, Patricio, >> >>>>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>>>> Does it help you? I think it gives you to remove workaround. >>>> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >>>> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >>>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. >>> Thanks for your information. >>> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. >>> I will modify and will test it after yours. >> Thanks :) >> >>>> Also my first impression was that it won't be that easy from a synchronization point of view to >>>> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >>>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >>>> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >>>> to me, how this has to be handled. >>> I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. >> Yes. To me it is unclear what synchronization is necessary, if it is called during a handshake. And >> also I'm unsure if a thread should do safepoint checks while executing a handshake. >> >> @Patricio, coming back to my question [1]: >> >> In the example you gave in your answer [2]: the java thread would execute a vm operation during a >> direct handshake operation, while the VMThread is actually in the middle of a VM_HandshakeAllThreads >> operation, waiting to handshake the same handshakee: why can't the VMThread just proceed? The >> handshakee would be safepoint safe, wouldn't it? > Because the VMThread would not be able to decrement _processing_sem to > claim the operation and execute the closure for that handshakee. If > another JavaThread is doing a direct handshake with that same handshakee > and called a new VM operation inside the execution of the > HandshakeClosure in do_handshake(), nobody would be able to decrement > the _processing_sem anymore until the original direct operation finished > and the semaphore is signaled again. So this can happen despite the > state of the handshakee is "handshake/safepoint safe". Changing the > nested VM operation to be a direct handshake would have the same issue. > Actually as the code is right now we would not even get pass setting the > handshake operation because in that case we would block in the > _handshake_turn_sem for the same reason. > > So changing VM_SetFramePop to use direct handshakes in the future will > probably create that last issue I mentioned. Now, since it is executed > at a safepoint, with your workaround in enter_interp_only_mode() we > avoid those nested issues in . Maybe 8239084 would have to be revisited > to address nested operations in all cases. It is not clear to me now > though if we should handle that in the handshake code or the caller of a > certain operation should know it might be called in a nested scenario > and should handle it. > > I'll look a bit more at the updated patch but at first glance looks good. > > Thanks! > > Patricio >> Thanks, Richard. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301677&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301677 >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301763&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301763 >> >> -----Original Message----- >> From: Yasumasa Suenaga >> Sent: Freitag, 24. April 2020 17:23 >> To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Richard, >> >> On 2020/04/24 23:44, Reingruber, Richard wrote: >>> Hi Yasumasa, >>> >>>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>>> Does it help you? I think it gives you to remove workaround. >>> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >>> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. >> Thanks for your information. >> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. >> I will modify and will test it after yours. >> >> >>> Also my first impression was that it won't be that easy from a synchronization point of view to >>> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >>> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >>> to me, how this has to be handled. >> I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. >> >> >> Thanks, >> >> Yasumasa >> >> >>> So it appears to me that it would be easier to push JDK-8242427 after this (JDK-8238585). >>> >>>> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >>> Would be interesting to see how you handled the issues above :) >>> >>> Thanks, Richard. >>> >>> [1] See question in comment https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030 >>> >>> -----Original Message----- >>> From: Yasumasa Suenaga >>> Sent: Freitag, 24. April 2020 13:34 >>> To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Richard, >>> >>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>> Does it help you? I think it gives you to remove workaround. >>> >>> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/04/24 17:18, Reingruber, Richard wrote: >>>> Hi Patricio, Vladimir, and Serguei, >>>> >>>> now that direct handshakes are available, I've updated the patch to make use of them. >>>> >>>> In addition I have done some clean-up changes I missed in the first webrev. >>>> >>>> Finally I have implemented the workaround suggested by Patricio to avoid nesting the handshake >>>> into the vm operation VM_SetFramePop [1] >>>> >>>> Kindly review again: >>>> >>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ >>>> Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ >>>> >>>> I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode can be replaced with a >>>> direct handshake: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238585 >>>> >>>> Testing: >>>> >>>> * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>>> >>>> * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737 >>>> >>>> Thanks, >>>> Richard. >>>> >>>> [1] An assertion in Handshake::execute_direct() fails, if called be VMThread, because it is no JavaThread. >>>> >>>> -----Original Message----- >>>> From: hotspot-dev On Behalf Of Reingruber, Richard >>>> Sent: Freitag, 14. Februar 2020 19:47 >>>> To: Patricio Chilano ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>>> Subject: RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>>> >>>> Hi Patricio, >>>> >>>> > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>>> > > handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>>> > > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>>> > > >>>> > > > Alternatively I think you could do something similar to what we do in >>>> > > > Deoptimization::deoptimize_all_marked(): >>>> > > > >>>> > > > EnterInterpOnlyModeClosure hs; >>>> > > > if (SafepointSynchronize::is_at_safepoint()) { >>>> > > > hs.do_thread(state->get_thread()); >>>> > > > } else { >>>> > > > Handshake::execute(&hs, state->get_thread()); >>>> > > > } >>>> > > > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>> > > > HandshakeClosure() constructor) >>>> > > >>>> > > Maybe this could be used also in the Handshake::execute() methods as general solution? >>>> > Right, we could also do that. Avoiding to clear the polling page in >>>> > HandshakeState::clear_handshake() should be enough to fix this issue and >>>> > execute a handshake inside a safepoint, but adding that "if" statement >>>> > in Hanshake::execute() sounds good to avoid all the extra code that we >>>> > go through when executing a handshake. I filed 8239084 to make that change. >>>> >>>> Thanks for taking care of this and creating the RFE. >>>> >>>> > >>>> > > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>> > > > always called in a nested operation or just sometimes. >>>> > > >>>> > > At least one execution path without vm operation exists: >>>> > > >>>> > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>>> > > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>>> > > JvmtiEventControllerPrivate::recompute_enabled() : void >>>> > > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>>> > > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>>> > > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>>> > > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>>> > > >>>> > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>>> > > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>>> > > encouraged to do it with a handshake :) >>>> > Ah! I think you can still do it with a handshake with the >>>> > Deoptimization::deoptimize_all_marked() like solution. I can change the >>>> > if-else statement with just the Handshake::execute() call in 8239084. >>>> > But up to you. : ) >>>> >>>> Well, I think that's enough encouragement :) >>>> I'll wait for 8239084 and try then again. >>>> (no urgency and all) >>>> >>>> Thanks, >>>> Richard. >>>> >>>> -----Original Message----- >>>> From: Patricio Chilano >>>> Sent: Freitag, 14. Februar 2020 15:54 >>>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>>> >>>> Hi Richard, >>>> >>>> On 2/14/20 9:58 AM, Reingruber, Richard wrote: >>>>> Hi Patricio, >>>>> >>>>> thanks for having a look. >>>>> >>>>> > I?m only commenting on the handshake changes. >>>>> > I see that operation VM_EnterInterpOnlyMode can be called inside >>>>> > operation VM_SetFramePop which also allows nested operations. Here is a >>>>> > comment in VM_SetFramePop definition: >>>>> > >>>>> > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>>> > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>>> > >>>>> > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>>> > could have a handshake inside a safepoint operation. The issue I see >>>>> > there is that at the end of the handshake the polling page of the target >>>>> > thread could be disarmed. So if the target thread happens to be in a >>>>> > blocked state just transiently and wakes up then it will not stop for >>>>> > the ongoing safepoint. Maybe I can file an RFE to assert that the >>>>> > polling page is armed at the beginning of disarm_safepoint(). >>>>> >>>>> I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>>>> handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>>>> Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>>>> >>>>> > Alternatively I think you could do something similar to what we do in >>>>> > Deoptimization::deoptimize_all_marked(): >>>>> > >>>>> > EnterInterpOnlyModeClosure hs; >>>>> > if (SafepointSynchronize::is_at_safepoint()) { >>>>> > hs.do_thread(state->get_thread()); >>>>> > } else { >>>>> > Handshake::execute(&hs, state->get_thread()); >>>>> > } >>>>> > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>>> > HandshakeClosure() constructor) >>>>> >>>>> Maybe this could be used also in the Handshake::execute() methods as general solution? >>>> Right, we could also do that. Avoiding to clear the polling page in >>>> HandshakeState::clear_handshake() should be enough to fix this issue and >>>> execute a handshake inside a safepoint, but adding that "if" statement >>>> in Hanshake::execute() sounds good to avoid all the extra code that we >>>> go through when executing a handshake. I filed 8239084 to make that change. >>>> >>>>> > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>>> > always called in a nested operation or just sometimes. >>>>> >>>>> At least one execution path without vm operation exists: >>>>> >>>>> JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>>>> JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>>>> JvmtiEventControllerPrivate::recompute_enabled() : void >>>>> JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>>>> JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>>>> JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>>>> jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>>>> >>>>> I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>>>> handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>>>> encouraged to do it with a handshake :) >>>> Ah! I think you can still do it with a handshake with the >>>> Deoptimization::deoptimize_all_marked() like solution. I can change the >>>> if-else statement with just the Handshake::execute() call in 8239084. >>>> But up to you.? : ) >>>> >>>> Thanks, >>>> Patricio >>>>> Thanks again, >>>>> Richard. >>>>> >>>>> -----Original Message----- >>>>> From: Patricio Chilano >>>>> Sent: Donnerstag, 13. Februar 2020 18:47 >>>>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>>>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>>>> >>>>> Hi Richard, >>>>> >>>>> I?m only commenting on the handshake changes. >>>>> I see that operation VM_EnterInterpOnlyMode can be called inside >>>>> operation VM_SetFramePop which also allows nested operations. Here is a >>>>> comment in VM_SetFramePop definition: >>>>> >>>>> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>>> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>>> >>>>> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>>> could have a handshake inside a safepoint operation. The issue I see >>>>> there is that at the end of the handshake the polling page of the target >>>>> thread could be disarmed. So if the target thread happens to be in a >>>>> blocked state just transiently and wakes up then it will not stop for >>>>> the ongoing safepoint. Maybe I can file an RFE to assert that the >>>>> polling page is armed at the beginning of disarm_safepoint(). >>>>> >>>>> I think one option could be to remove >>>>> SafepointMechanism::disarm_if_needed() in >>>>> HandshakeState::clear_handshake() and let each JavaThread disarm itself >>>>> for the handshake case. >>>>> >>>>> Alternatively I think you could do something similar to what we do in >>>>> Deoptimization::deoptimize_all_marked(): >>>>> >>>>> ? EnterInterpOnlyModeClosure hs; >>>>> ? if (SafepointSynchronize::is_at_safepoint()) { >>>>> ??? hs.do_thread(state->get_thread()); >>>>> ? } else { >>>>> ??? Handshake::execute(&hs, state->get_thread()); >>>>> ? } >>>>> (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>>> HandshakeClosure() constructor) >>>>> >>>>> I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>>> always called in a nested operation or just sometimes. >>>>> >>>>> Thanks, >>>>> Patricio >>>>> >>>>> On 2/12/20 7:23 AM, Reingruber, Richard wrote: >>>>>> // Repost including hotspot runtime and gc lists. >>>>>> // Dean Long suggested to do so, because the enhancement replaces a vm operation >>>>>> // with a handshake. >>>>>> // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html >>>>>> >>>>>> Hi, >>>>>> >>>>>> could I please get reviews for this small enhancement in hotspot's jvmti implementation: >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >>>>>> >>>>>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to >>>>>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. >>>>>> >>>>>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. >>>>>> >>>>>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>>>>> >>>>>> Thanks, Richard. >>>>>> >>>>>> See also my question if anyone knows a reason for making the compiled methods not_entrant: >>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html From igor.ignatyev at oracle.com Sat Apr 25 13:51:13 2020 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Sat, 25 Apr 2020 06:51:13 -0700 Subject: RFR(S/T) : 8243568 : serviceability/logging/TestLogRotation.java uses 'test.java.opts' and not 'test.vm.opts' In-Reply-To: References: Message-ID: Thanks Chris. I can?t help but wonder if we should move all tests from serviceability/logging to runtime then. ? Igor > On Apr 24, 2020, at 3:53 PM, Chris Plummer wrote: > > ?Adding hotspot-runtime-dev since logging is owned by runtime, not serviceability. > > Chris > >> On 4/24/20 3:41 PM, Leonid Mesnik wrote: >> Looks good. (Need a 'R'eview.) >> >> Leonid. >> >>>> On Apr 24, 2020, at 3:30 PM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 >>>> 8 lines changed: 0 ins; 6 del; 2 mod; >>> Hi all, >>> >>> could you please review this small and trivial patch which updates serviceability/logging/TestLogRotation.java test to pass both 'test.java.opts' and not 'test.vm.opts' ? to do that, the patch removes the custom logic of handling test.java.opts and just uses ProcessTools.createJavaProcessBuilder(boolean addTestVmAndJavaOptions=true, String...), which prepends values of both properties. >>> from JBS: >>>> serviceability/logging/TestLogRotation.java test use 'test.java.opts' to get external vm flags, yet actually external flags are split b/w 'test.java.opts' and 'test.vm.opts' and in the majority of cases all external flags are set listed in 'test.vm.opts' so the test should be updated to read both. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243568 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 >>> >>> Thanks, >>> -- Igor > From daniil.x.titov at oracle.com Sat Apr 25 16:11:26 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Sat, 25 Apr 2020 09:11:26 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same In-Reply-To: <0df530e0-0ef7-10cd-7226-c6ebbca7654f@oracle.com> References: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> <9deb907b-0cbb-2a05-73a3-1aa4c6f5fc94@oracle.com> <9523cda9-66a0-e609-f199-117f02d907d7@oracle.com> <1F96342D-332B-4ABE-9BCC-952969421805@oracle.com> <0df530e0-0ef7-10cd-7226-c6ebbca7654f@oracle.com> Message-ID: Hi Serguei, Please review a new version of the webrev [1] that changes the condition as you suggested. Please note then in both cases we need break from the loop : the case when it is a first attempt and the conditions are met and the case when it is a second attempt. [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.03 [2] https://bugs.openjdk.java.net/browse/JDK-8242239 Thank you, Daniil From: "serguei.spitsyn at oracle.com" Date: Saturday, April 25, 2020 at 12:06 AM To: Daniil Titov , Chris Plummer , serviceability-dev Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same Hi Daniil, Thank you for the update. On 4/24/20 22:22, Daniil Titov wrote: Hi Chris and Serguei, Please review a new version of the fix [1] that makes the tests try to repeat the check only once. Regarding the question Serguei asked: 97 while(true) { 113 if (mbeanCount * 2 == counterCount || isSecondAttempt) { 114 assertEquals(mbeanCount * 2, counterCount); I doubt, the assert is really needed. we need the assert here to make the test fail in case if it is a second attempt and the conditions are not met. A space is still needed in "while(true)." 111 if (mbeanCount * 2 == counterCount || isSecondAttempt) { 112 assertEquals(mbeanCount * 2, counterCount); 113 break; 114 } The code above is a little confusing as we have to logically separate the assert and break cases. Would something like below be more straightforward?: ???? if (mbeanCount * 2 == counterCount) { ???????? break; ???? } ???? if (isSecondAttempt) { ? ? ? ?? assertEquals(mbeanCount * 2 != counterCount); ???? } Otherwise, the update looks good. Thanks, Serguei [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.02/ [2] https://bugs.openjdk.java.net/browse/JDK-8242239 Thank you, Daniil From: serviceability-dev mailto:serviceability-dev-bounces at openjdk.java.net on behalf of Daniil Titov mailto:daniil.x.titov at oracle.com Date: Friday, April 24, 2020 at 2:08 PM To: Chris Plummer mailto:chris.plummer at oracle.com, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same Hi Chris, ? I agree with you. I will change the test to retry just once. ? Thank you, Daniil ? ? From: Chris Plummer mailto:chris.plummer at oracle.com Date: Friday, April 24, 2020 at 1:27 PM To: Daniil Titov mailto:daniil.x.titov at oracle.com, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same ? Hi Daniil, I think a retry count more in line with our current expectations would make more sense since it is deterministic how many retries are might actually be needed. You just used a large number in case more ?lazy-registered? mbeans are added in the future, but if this is the case then maybe even 10 is not enough. thanks, Chris On 4/24/20 12:36 PM, Daniil Titov wrote: Hi Serguei and Chris, ? Thank you for your comments. ? I wanted to make the fix ?more generic ?and not limit it just to Graal management bean. In this case we could expect that after the first retry is triggered by Graal MBean registration some other ?lazy-registered? MBean got registered and the test might fail. To avoid this we need to allow test to make at least several retry attempts before failing.? If number 10 looks as too high we could make it 5 or even 3. This should not affect the test run-time unless the test starts failing for some other reason than we expect. ?In the new webrev I will also correct ?the iteration counting (as Chris mentioned) and fix typos. ? Thanks again, Daniil ? From: mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com Date: Friday, April 24, 2020 at 11:48 AM To: Chris Plummer mailto:chris.plummer at oracle.com, Daniil Titov mailto:daniil.x.titov at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same ? Hi Daniil, Besides what Chris is pointed out the fix looks good. Minor: ? 97???????? while(true) { 113???????????? if(mbeanCount * 2 == counterCount || retryCounter++ > MAX_RETRY_ATTEMPT) { 114???????????????? assertEquals(mbeanCount * 2, counterCount); ?Space is missed in while and if. ?I doubt, the assert is really needed. ? 96???????? // is running ( e.g. Graal MBean). In this case just retry the test. ?Extra space before "e.g.". Thanks, Serguei On 4/24/20 11:30, Chris Plummer wrote: Hi Daniil, ? 84???????????? // If new MBean (e.g. Graal MBean) is registred while the test is running names1, ?106???????????? // If new MBean (e.g. Graal MBean) is registred while the test is running mbeans1, registred -> registered ',' after "running" Just wondering how you chose 10 as the number of retries. Seems excessive. Shouldn't the problem turn up at most 1 time and therefore only 1 retry is needed. ? 76???????? int counter = 0; ? 86???????????? if (sameSize(names1, names2, names3) || counter++ > MAX_RETRY_ATTEMPTS) { The way the checks are done you will actually end up retrying MAX_RETRY_ATTEMPTS+1 times. For example, if MAX_RETRY_ATTEMPTS is 1, first time through the loop counter is 0 so a retry is allowed. Second time through the loop counter is 1, so a retry is allowed again. thanks, Chris On 4/18/20 11:30 AM, Daniil Titov wrote: Please review the change that fixes the failure of javax/management/generified/GenericTest.java? and ? javax/management/query/CustomQueryTest.java tests when Graal is on. The tests checks that calls of management API are consistent and return the same set of MBeans.? However, when Graal is on the Graal MBean might be registered between the calls that in turn makes the results inconsistent and the tests fail. The fix makes the test aware that some MBean might be registered while the checks run and if it happens the tests repeat the check. Testing : Mach5 tests with Graal on and tier1-tier3 tests passed. [1]? http://cr.openjdk.java.net/~dtitov/8242239/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8242239 Thanks, Daniil ? From serguei.spitsyn at oracle.com Sat Apr 25 22:42:02 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 25 Apr 2020 15:42:02 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same In-Reply-To: References: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> <9deb907b-0cbb-2a05-73a3-1aa4c6f5fc94@oracle.com> <9523cda9-66a0-e609-f199-117f02d907d7@oracle.com> <1F96342D-332B-4ABE-9BCC-952969421805@oracle.com> <0df530e0-0ef7-10cd-7226-c6ebbca7654f@oracle.com> Message-ID: <50eab649-7893-5ca1-0ddd-9d90daf73103@oracle.com> Hi Daniil, Thank you for the update. It looks good. Thanks, Serguei On 4/25/20 09:11, Daniil Titov wrote: > Hi Serguei, > > Please review a new version of the webrev [1] that changes the condition > as you suggested. Please note then in both cases we need break from the loop : the case when > it is a first attempt and the conditions are met and the case when it is a second attempt. > > > [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.03 > [2] https://bugs.openjdk.java.net/browse/JDK-8242239 > > Thank you, > Daniil > > > From: "serguei.spitsyn at oracle.com" > Date: Saturday, April 25, 2020 at 12:06 AM > To: Daniil Titov , Chris Plummer , serviceability-dev > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Daniil, > > Thank you for the update. > > On 4/24/20 22:22, Daniil Titov wrote: > Hi Chris and Serguei, > > Please review a new version of the fix [1] that makes the tests try to repeat the check only once. > > Regarding the question Serguei asked: > > 97 while(true) { > 113 if (mbeanCount * 2 == counterCount || isSecondAttempt) { > 114 assertEquals(mbeanCount * 2, counterCount); > I doubt, the assert is really needed. > we need the assert here to make the test fail in case if it is a second attempt and the conditions are not met. > > A space is still needed in "while(true)." > 111 if (mbeanCount * 2 == counterCount || isSecondAttempt) { > 112 assertEquals(mbeanCount * 2, counterCount); > 113 break; > 114 } > The code above is a little confusing as we have to logically separate the assert and break cases. > Would something like below be more straightforward?: > ???? if (mbeanCount * 2 == counterCount) { > ???????? break; > ???? } > ???? if (isSecondAttempt) { > ? ? ? ?? assertEquals(mbeanCount * 2 != counterCount); > ???? } > > Otherwise, the update looks good. > > Thanks, > Serguei > > > [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.02/ > [2] https://bugs.openjdk.java.net/browse/JDK-8242239 > > Thank you, > Daniil > > > From: serviceability-dev mailto:serviceability-dev-bounces at openjdk.java.net on behalf of Daniil Titov mailto:daniil.x.titov at oracle.com > Date: Friday, April 24, 2020 at 2:08 PM > To: Chris Plummer mailto:chris.plummer at oracle.com, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Chris, > > I agree with you. I will change the test to retry just once. > > Thank you, > Daniil > > > From: Chris Plummer mailto:chris.plummer at oracle.com > Date: Friday, April 24, 2020 at 1:27 PM > To: Daniil Titov mailto:daniil.x.titov at oracle.com, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Daniil, > > I think a retry count more in line with our current expectations would make more sense since it is deterministic how many retries are might actually be needed. You just used a large number in case more ?lazy-registered? mbeans are added in the future, but if this is the case then maybe even 10 is not enough. > > thanks, > > Chris > > On 4/24/20 12:36 PM, Daniil Titov wrote: > Hi Serguei and Chris, > > Thank you for your comments. > > I wanted to make the fix ?more generic ?and not limit it just to Graal management bean. In this case we could expect that after the first retry is triggered by Graal MBean registration some other ?lazy-registered? MBean got registered and the test might fail. To avoid this we need to allow test to make at least several retry attempts before failing.? If number 10 looks as too high we could make it 5 or even 3. This should not affect the test run-time unless the test starts failing for some other reason than we expect. ?In the new webrev I will also correct ?the iteration counting (as Chris mentioned) and fix typos. > > Thanks again, > Daniil > > From: mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com > Date: Friday, April 24, 2020 at 11:48 AM > To: Chris Plummer mailto:chris.plummer at oracle.com, Daniil Titov mailto:daniil.x.titov at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Daniil, > > Besides what Chris is pointed out the fix looks good. > > Minor: > ? 97???????? while(true) { > 113???????????? if(mbeanCount * 2 == counterCount || retryCounter++ > MAX_RETRY_ATTEMPT) { > 114???????????????? assertEquals(mbeanCount * 2, counterCount); > ?Space is missed in while and if. > ?I doubt, the assert is really needed. > ? 96???????? // is running ( e.g. Graal MBean). In this case just retry the test. > ?Extra space before "e.g.". > > Thanks, > Serguei > > > On 4/24/20 11:30, Chris Plummer wrote: > Hi Daniil, > > ? 84???????????? // If new MBean (e.g. Graal MBean) is registred while the test is running names1, > ?106???????????? // If new MBean (e.g. Graal MBean) is registred while the test is running mbeans1, > > registred -> registered > ',' after "running" > > Just wondering how you chose 10 as the number of retries. Seems excessive. Shouldn't the problem turn up at most 1 time and therefore only 1 retry is needed. > > ? 76???????? int counter = 0; > ? 86???????????? if (sameSize(names1, names2, names3) || counter++ > MAX_RETRY_ATTEMPTS) { > > The way the checks are done you will actually end up retrying MAX_RETRY_ATTEMPTS+1 times. For example, if MAX_RETRY_ATTEMPTS is 1, first time through the loop counter is 0 so a retry is allowed. Second time through the loop counter is 1, so a retry is allowed again. > > thanks, > > Chris > > On 4/18/20 11:30 AM, Daniil Titov wrote: > > > > Please review the change that fixes the failure of javax/management/generified/GenericTest.java? and > ? javax/management/query/CustomQueryTest.java tests when Graal is on. > > The tests checks that calls of management API are consistent and return the same set of MBeans.? However, > when Graal is on the Graal MBean might be registered between the calls that in turn makes the results > inconsistent and the tests fail. > > The fix makes the test aware that some MBean might be registered while the checks run and if it happens the tests repeat the check. > > Testing : Mach5 tests with Graal on and tier1-tier3 tests passed. > > [1]? http://cr.openjdk.java.net/~dtitov/8242239/webrev.01/ > [2] https://bugs.openjdk.java.net/browse/JDK-8242239 > > Thanks, > Daniil > > > > > > > > > > > > > > > > > > > From linzang at tencent.com Sun Apr 26 03:10:02 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Sun, 26 Apr 2020 03:10:02 +0000 Subject: RFR(L): 8215624: add parallel heap inspection support for jmap histo(G1)(Internet mail) In-Reply-To: <94C0D11E-F395-4FE4-9ECE-5ECC84B3AE1B@tencent.com> References: <94C0D11E-F395-4FE4-9ECE-5ECC84B3AE1B@tencent.com> Message-ID: <09702D94-F53C-413D-A156-B7390D689BC6@tencent.com> Hi Stefan and Paul? I have made a new patch based on your comments and Stefan's Poc code: Webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_03/ Delta(based on Stefan's change:) : http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_03-delta/webrev_03-delta/ And Here are main changed I made and want to discuss with you: 1. changed"parallelThreadNum=" to "parallel=" for jmap -histo options. 2. Add logic to test where parallelHeapInspection is fail, in heapInspection.cpp This is because the parHeapInspectTask create thread local KlassInfoTable in it's work() method, and this may fail because of native OOM, in this case, the parallel should fail and serial heap inspection can be tried. One more thing I want discuss with you is about the member "_success" of parHeapInspectTask, when native OOM happenes, it is set to false. And since this "set" operation can be conducted in multiple threads, should it be atomic ops? IMO, this is not necessary because "_success" can only be set to false, and there is no way to change it from back to true after the ParHeapInspectTask instance is created, so it is save to be non-atomic, do you agree with that? 3. make CollectedHeap::run_task() be an abstract virtual func, so that every subclass of collectedHeap should support it, so later implementation of new collectedHeap will not miss the "parallel" features. The problem I want to discuss with you is about epsilonHeap and SerialHeap, as they may not need parallel heap iteration, so I only make task->work(0), in case the run_task() is invoked someway in future. Another way is to left run_task() unimplemented, which one do you think is better? And also please help take a look at the zHeap, as there is a class zTask that wrap the abstractGangTask, and the collectedHeap::run_task() only accept AbstraceGangTask* as argument, so I made a delegate class to adapt it , please see src/hotspot/share/gc/z/zHeap.cpp. There maybe other better ways to sovle the above problems, welcome for any comments, Thanks! BRs, Lin ?On 2020/4/23, 11:08 AM, "linzang(??)" wrote: Thanks Paul! I agree with using "parallel", will make the update in next patch, Thanks for help update the CSR. BRs, Lin On 2020/4/23, 4:42 AM, "Hohensee, Paul" wrote: For the interface, I'd use "parallel" instead of "parallelThreadNum". All the other options are lower case, and it's a lot easier to type "parallel". I took the liberty of updating the CSR. If you're ok with it, you might want to change variable names and such, plus of course JMap.usage. Thanks, Paul On 4/22/20, 2:29 AM, "serviceability-dev on behalf of linzang(??)" wrote: Dear Stefan, Thanks a lot! I agree with you to decouple the heap inspection code with GC's. I will start from your POC code, may discuss with you later. BRs, Lin On 2020/4/22, 5:14 PM, "Stefan Karlsson" wrote: Hi Lin, I took a look at this earlier and saw that the heap inspection code is strongly coupled with the CollectedHeap and G1CollectedHeap. I'd prefer if we'd abstract this away, so that the GCs only provide a "parallel object iteration" interface, and the heap inspection code is kept elsewhere. I started experimenting with doing that, but other higher-priority (to me) tasks have had to take precedence. I've uploaded my work-in-progress / proof-of-concept: https://cr.openjdk.java.net/~stefank/8215624/webrev.01.delta/ https://cr.openjdk.java.net/~stefank/8215624/webrev.01/ The current code doesn't handle the lifecycle (deletion) of the ParallelObjectIterators. There's also code left unimplemented in around CollectedHeap::run_task. However, I think this could work as a basis to pull out the heap inspection code out of the GCs. Thanks, StefanK On 2020-04-22 02:21, linzang(??) wrote: > Dear all, > May I ask you help to review? This RFR has been there for quite a while. > Thanks! > > BRs, > Lin > > > On 2020/3/16, 5:18 PM, "linzang(??)" wrote:> > >> Just update a new path, my preliminary measure show about 3.5x speedup of jmap histo on a nearly full 4GB G1 heap (8-core platform with parallel thread number set to 4). >> webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_02/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> BRs, >> Lin >> > On 2020/3/2, 9:56 PM, "linzang(??)" wrote: >> > >> > Dear all, >> > Let me try to ease the reviewing work by some explanation :P >> > The patch's target is to speed up jmap -histo for heap iteration, from my experience it is necessary for large heap investigation. E.g in bigData scenario I have tried to conduct jmap -histo against 180GB heap, it does take quite a while. >> > And if my understanding is corrent, even the jmap -histo without "live" option does heap inspection with heap lock acquired. so it is very likely to block mutator thread in allocation-sensitive scenario. I would say the faster the heap inspection does, the shorter the mutator be blocked. This is parallel iteration for jmap is necessary. >> > I think the parallel heap inspection should be applied to all kind of heap. However, consider the heap layout are different for GCs, much time is required to understand all kinds of the heap layout to make the whole change. IMO, It is not wise to have a huge patch for the whole solution at once, and it is even harder to review it. So I plan to implement it incrementally, the first patch (this one) is going to confirm the implemention detail of how jmap accept the new option, passes it to attachListener of the jvm process and then how to make the parallel inspection closure be generic enough to make it easy to extend to different heap layout. And also how to implement the heap inspection in specific gc's heap. This patch use G1's heap as the begining. >> > This patch actually do several things: >> > 1. Add an option "parallelThreadNum=" to jmap -histo, the default behavior is to set N to 0, means let's JVM decide how many threads to use for heap inspection. Set this option to 1 will disable parallel heap inspection. (more details in CSR: https://bugs.openjdk.java.net/browse/JDK-8239290) >> > 2. Make a change in how Jmap passing arguments, changes in http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html, originally it pass options as separate arguments to attachListener, this patch change to that all options be compose to a single string. So the arg_count_max in attachListener.hpp do not need to be changed, and hence avoid the compatibility issue, as disscussed at https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027334.html >> > 3. Add an abstract class ParHeapInspectTask in heapInspection.hpp / heapInspection.cpp, It's work(uint worker_id) method prepares the data structure (KlassInfoTable) need for every parallel worker thread, and then call do_object_iterate_parallel() which is heap specific implementation. I also added some machenism in KlassInfoTable to support parallel iteration, such as merge(). >> > 4. In specific heap (G1 in this patch), create a subclass of ParHeapInspectTask, implement the do_object_iterate_parallel() for parallel heap inspection. For G1, it simply invoke g1CollectedHeap's object_iterate_parallel(). >> > 5. Add related test. >> > 6. it may be easy to extend this patch for other kinds of heap by creating subclass of ParHeapInspectTask and implement the do_object_iterate_parallel(). >> > >> > Hope these info could help on code review and initate the discussion :-) >> > Thanks! >> > >> > BRs, >> > Lin >> > >On 2020/2/19, 9:40 AM, "linzang(??)" wrote:. >> > > >> > > Re-post this RFR with correct enhancement number to make it trackable. >> > > please ignore the previous wrong post. sorry for troubles. >> > > >> > > webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/ >> > > Hi bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > -------------- >> > > Lin >> > > >Hi Lin, > > > > > >> > > >Could you, please, re-post your RFR with the right enhancement number in >> > > >the message subject? >> > > >It will be more trackable this way. >> > > > >> > > >Thanks, >> > > >Serguei >> > > > >> > > > >> > > >On 2/17/20 10:29 PM, linzang(??) wrote: >> > > >> Dear David, >> > > >> Thanks a lot! >> > > >> I have updated the refined code to http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_01/. >> > > >> IMHO the parallel heap inspection can be extended to all kinds of heap as long as the heap layout can support parallel iteration. >> > > >> Maybe we can firstly use this webrev to discuss how to implement it, because I am not sure my current implementation is an appropriate way to communicate with collectedHeap, then we can extend the solution to other kinds of heap. >> > > >> >> > > >> Thanks, >> > > >> -------------- >> > > >> Lin >> > > >>> Hi Lin, >> > > >>> >> > > >>> Adding in hotspot-gc-dev as they need to see how this interacts with GC >> > > >>> worker threads, and whether it needs to be extended beyond G1. >> > > >>> >> > > >>> I happened to spot one nit when browsing: >> > > >>> >> > > >>> src/hotspot/share/gc/shared/collectedHeap.hpp >> > > >>> >> > > >>> + virtual bool run_par_heap_inspect_task(KlassInfoTable* cit, >> > > >>> + BoolObjectClosure* filter, >> > > >>> + size_t* missed_count, >> > > >>> + size_t thread_num) { >> > > >>> + return NULL; >> > > >>> >> > > >>> s/NULL/false/ >> > > >>> >> > > >>> Cheers, >> > > >>> David > > > > >>> >> > > >>> On 18/02/2020 2:15 pm, linzang(??) wrote: >> > > >>>> Dear All, >> > > >>>> May I ask your help to review the follow changes: >> > > >>>> webrev: >> > > >>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_00/ >> > > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > >>>> related CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > >>>> This patch enable parallel heap inspection of G1 for jmap histo. >> > > >>>> my simple test shown it can speed up 2x of jmap -histo with >> > > >>>> parallelThreadNum set to 2 for heap at ~500M on 4-core platform. >> > > >>>> >> > > >>>> ------------------------------------------------------------------------ >> > > >>>> BRs, >> > > >>>> Lin >> > > >> > >> > > > > > > From david.holmes at oracle.com Sun Apr 26 22:38:28 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Apr 2020 08:38:28 +1000 Subject: RFR(S/T) : 8243568 : serviceability/logging/TestLogRotation.java uses 'test.java.opts' and not 'test.vm.opts' In-Reply-To: References: Message-ID: <2da11c2b-106b-c5f8-b641-eb12f6089388@oracle.com> On 25/04/2020 11:51 pm, Igor Ignatev wrote: > Thanks Chris. I can?t help but wonder if we should move all tests from serviceability/logging to runtime then. Actually unified logging (JEP 158) was defined as a serviceability feature: https://bugs.openjdk.java.net/browse/JDK-8046148 IIUC the core functional tests are under serviceability/logging, whereas a test that relates to logging of a particular item in the VM is filed under the component area of the item. Anyway this fix seems fine to me. Thanks, David > ? Igor > >> On Apr 24, 2020, at 3:53 PM, Chris Plummer wrote: >> >> ?Adding hotspot-runtime-dev since logging is owned by runtime, not serviceability. >> >> Chris >> >>> On 4/24/20 3:41 PM, Leonid Mesnik wrote: >>> Looks good. (Need a 'R'eview.) >>> >>> Leonid. >>> >>>>> On Apr 24, 2020, at 3:30 PM, Igor Ignatyev wrote: >>>> >>>> http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 >>>>> 8 lines changed: 0 ins; 6 del; 2 mod; >>>> Hi all, >>>> >>>> could you please review this small and trivial patch which updates serviceability/logging/TestLogRotation.java test to pass both 'test.java.opts' and not 'test.vm.opts' ? to do that, the patch removes the custom logic of handling test.java.opts and just uses ProcessTools.createJavaProcessBuilder(boolean addTestVmAndJavaOptions=true, String...), which prepends values of both properties. >>>> from JBS: >>>>> serviceability/logging/TestLogRotation.java test use 'test.java.opts' to get external vm flags, yet actually external flags are split b/w 'test.java.opts' and 'test.vm.opts' and in the majority of cases all external flags are set listed in 'test.vm.opts' so the test should be updated to read both. >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243568 >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 >>>> >>>> Thanks, >>>> -- Igor >> > From igor.ignatyev at oracle.com Mon Apr 27 01:11:56 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sun, 26 Apr 2020 18:11:56 -0700 Subject: RFR(S/T) : 8243568 : serviceability/logging/TestLogRotation.java uses 'test.java.opts' and not 'test.vm.opts' In-Reply-To: <2da11c2b-106b-c5f8-b641-eb12f6089388@oracle.com> References: <2da11c2b-106b-c5f8-b641-eb12f6089388@oracle.com> Message-ID: <8EB2D1A4-5D52-408C-9163-DEBF0C0E3CE5@oracle.com> David, Leonid, thank you for review, pushed. -- Igor > On Apr 26, 2020, at 3:38 PM, David Holmes wrote: > > On 25/04/2020 11:51 pm, Igor Ignatev wrote: >> Thanks Chris. I can?t help but wonder if we should move all tests from serviceability/logging to runtime then. > > Actually unified logging (JEP 158) was defined as a serviceability feature: > > https://bugs.openjdk.java.net/browse/JDK-8046148 > > IIUC the core functional tests are under serviceability/logging, whereas a test that relates to logging of a particular item in the VM is filed under the component area of the item. > > Anyway this fix seems fine to me. > > Thanks, > David > > >> ? Igor >>> On Apr 24, 2020, at 3:53 PM, Chris Plummer wrote: >>> >>> ?Adding hotspot-runtime-dev since logging is owned by runtime, not serviceability. >>> >>> Chris >>> >>>> On 4/24/20 3:41 PM, Leonid Mesnik wrote: >>>> Looks good. (Need a 'R'eview.) >>>> >>>> Leonid. >>>> >>>>>> On Apr 24, 2020, at 3:30 PM, Igor Ignatyev wrote: >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 >>>>>> 8 lines changed: 0 ins; 6 del; 2 mod; >>>>> Hi all, >>>>> >>>>> could you please review this small and trivial patch which updates serviceability/logging/TestLogRotation.java test to pass both 'test.java.opts' and not 'test.vm.opts' ? to do that, the patch removes the custom logic of handling test.java.opts and just uses ProcessTools.createJavaProcessBuilder(boolean addTestVmAndJavaOptions=true, String...), which prepends values of both properties. >>>>> from JBS: >>>>>> serviceability/logging/TestLogRotation.java test use 'test.java.opts' to get external vm flags, yet actually external flags are split b/w 'test.java.opts' and 'test.vm.opts' and in the majority of cases all external flags are set listed in 'test.vm.opts' so the test should be updated to read both. >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243568 >>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 >>>>> >>>>> Thanks, >>>>> -- Igor >>> From stefan.karlsson at oracle.com Mon Apr 27 08:32:36 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 27 Apr 2020 10:32:36 +0200 Subject: RFR(L): 8215624: add parallel heap inspection support for jmap histo(G1)(Internet mail) In-Reply-To: <09702D94-F53C-413D-A156-B7390D689BC6@tencent.com> References: <94C0D11E-F395-4FE4-9ECE-5ECC84B3AE1B@tencent.com> <09702D94-F53C-413D-A156-B7390D689BC6@tencent.com> Message-ID: <4751f476-1e7a-490f-80c5-96b58eb25191@oracle.com> Hi Lin, On 2020-04-26 05:10, linzang(??) wrote: > Hi Stefan and Paul? > I have made a new patch based on your comments and Stefan's Poc code: > Webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_03/ > Delta(based on Stefan's change:) : http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_03-delta/webrev_03-delta/ Thanks for providing a delta patch. It makes it much easier to look at, and more likely for reviewers to continue reviewing. I'm going to continue focusing on the GC parts, and leave the rest to others to review. > > And Here are main changed I made and want to discuss with you: > 1. changed"parallelThreadNum=" to "parallel=" for jmap -histo options. > 2. Add logic to test where parallelHeapInspection is fail, in heapInspection.cpp > This is because the parHeapInspectTask create thread local KlassInfoTable in it's work() method, and this may fail because of native OOM, in this case, the parallel should fail and serial heap inspection can be tried. > One more thing I want discuss with you is about the member "_success" of parHeapInspectTask, when native OOM happenes, it is set to false. And since this "set" operation can be conducted in multiple threads, should it be atomic ops? IMO, this is not necessary because "_success" can only be set to false, and there is no way to change it from back to true after the ParHeapInspectTask instance is created, so it is save to be non-atomic, do you agree with that? In these situations you should be using the Atomic::load/store primitives. We're moving toward a later C++ standard were data races are considered undefined behavior. > 3. make CollectedHeap::run_task() be an abstract virtual func, so that every subclass of collectedHeap should support it, so later implementation of new collectedHeap will not miss the "parallel" features. > The problem I want to discuss with you is about epsilonHeap and SerialHeap, as they may not need parallel heap iteration, so I only make task->work(0), in case the run_task() is invoked someway in future. Another way is to left run_task() unimplemented, which one do you think is better? I don't have a strong opinion about this. And also please help take a look at the zHeap, as there is a class zTask that wrap the abstractGangTask, and the collectedHeap::run_task() only accept AbstraceGangTask* as argument, so I made a delegate class to adapt it , please see src/hotspot/share/gc/z/zHeap.cpp. > > There maybe other better ways to sovle the above problems, welcome for any comments, Thanks! I've created a few cleanups and changes on top of your latest patch: https://cr.openjdk.java.net/~stefank/8215624/webrev.02.delta https://cr.openjdk.java.net/~stefank/8215624/webrev.02 - Adding Atomic::load/store. - Removing the time measurement in the run_task. I renamed G1's function to run_task_timed. If we need this outside of G1, we can rethink the API at that point. - ZGC style cleanups Thanks, StefanK > > BRs, > Lin > > ?On 2020/4/23, 11:08 AM, "linzang(??)" wrote: > > Thanks Paul! I agree with using "parallel", will make the update in next patch, Thanks for help update the CSR. > > BRs, > Lin > > On 2020/4/23, 4:42 AM, "Hohensee, Paul" wrote: > > For the interface, I'd use "parallel" instead of "parallelThreadNum". All the other options are lower case, and it's a lot easier to type "parallel". I took the liberty of updating the CSR. If you're ok with it, you might want to change variable names and such, plus of course JMap.usage. > > Thanks, > Paul > > On 4/22/20, 2:29 AM, "serviceability-dev on behalf of linzang(??)" wrote: > > Dear Stefan, > > Thanks a lot! I agree with you to decouple the heap inspection code with GC's. > I will start from your POC code, may discuss with you later. > > > BRs, > Lin > > On 2020/4/22, 5:14 PM, "Stefan Karlsson" wrote: > > Hi Lin, > > I took a look at this earlier and saw that the heap inspection code is > strongly coupled with the CollectedHeap and G1CollectedHeap. I'd prefer > if we'd abstract this away, so that the GCs only provide a "parallel > object iteration" interface, and the heap inspection code is kept elsewhere. > > I started experimenting with doing that, but other higher-priority (to > me) tasks have had to take precedence. > > I've uploaded my work-in-progress / proof-of-concept: > https://cr.openjdk.java.net/~stefank/8215624/webrev.01.delta/ > https://cr.openjdk.java.net/~stefank/8215624/webrev.01/ > > The current code doesn't handle the lifecycle (deletion) of the > ParallelObjectIterators. There's also code left unimplemented in around > CollectedHeap::run_task. However, I think this could work as a basis to > pull out the heap inspection code out of the GCs. > > Thanks, > StefanK > > On 2020-04-22 02:21, linzang(??) wrote: > > Dear all, > > May I ask you help to review? This RFR has been there for quite a while. > > Thanks! > > > > BRs, > > Lin > > > > > On 2020/3/16, 5:18 PM, "linzang(??)" wrote:> > > > >> Just update a new path, my preliminary measure show about 3.5x speedup of jmap histo on a nearly full 4GB G1 heap (8-core platform with parallel thread number set to 4). > >> webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_02/ > >> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 > >> CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 > >> BRs, > >> Lin > >> > On 2020/3/2, 9:56 PM, "linzang(??)" wrote: > >> > > >> > Dear all, > >> > Let me try to ease the reviewing work by some explanation :P > >> > The patch's target is to speed up jmap -histo for heap iteration, from my experience it is necessary for large heap investigation. E.g in bigData scenario I have tried to conduct jmap -histo against 180GB heap, it does take quite a while. > >> > And if my understanding is corrent, even the jmap -histo without "live" option does heap inspection with heap lock acquired. so it is very likely to block mutator thread in allocation-sensitive scenario. I would say the faster the heap inspection does, the shorter the mutator be blocked. This is parallel iteration for jmap is necessary. > >> > I think the parallel heap inspection should be applied to all kind of heap. However, consider the heap layout are different for GCs, much time is required to understand all kinds of the heap layout to make the whole change. IMO, It is not wise to have a huge patch for the whole solution at once, and it is even harder to review it. So I plan to implement it incrementally, the first patch (this one) is going to confirm the implemention detail of how jmap accept the new option, passes it to attachListener of the jvm process and then how to make the parallel inspection closure be generic enough to make it easy to extend to different heap layout. And also how to implement the heap inspection in specific gc's heap. This patch use G1's heap as the begining. > >> > This patch actually do several things: > >> > 1. Add an option "parallelThreadNum=" to jmap -histo, the default behavior is to set N to 0, means let's JVM decide how many threads to use for heap inspection. Set this option to 1 will disable parallel heap inspection. (more details in CSR: https://bugs.openjdk.java.net/browse/JDK-8239290) > >> > 2. Make a change in how Jmap passing arguments, changes in http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html, originally it pass options as separate arguments to attachListener, this patch change to that all options be compose to a single string. So the arg_count_max in attachListener.hpp do not need to be changed, and hence avoid the compatibility issue, as disscussed at https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027334.html > >> > 3. Add an abstract class ParHeapInspectTask in heapInspection.hpp / heapInspection.cpp, It's work(uint worker_id) method prepares the data structure (KlassInfoTable) need for every parallel worker thread, and then call do_object_iterate_parallel() which is heap specific implementation. I also added some machenism in KlassInfoTable to support parallel iteration, such as merge(). > >> > 4. In specific heap (G1 in this patch), create a subclass of ParHeapInspectTask, implement the do_object_iterate_parallel() for parallel heap inspection. For G1, it simply invoke g1CollectedHeap's object_iterate_parallel(). > >> > 5. Add related test. > >> > 6. it may be easy to extend this patch for other kinds of heap by creating subclass of ParHeapInspectTask and implement the do_object_iterate_parallel(). > >> > > >> > Hope these info could help on code review and initate the discussion :-) > >> > Thanks! > >> > > >> > BRs, > >> > Lin > >> > >On 2020/2/19, 9:40 AM, "linzang(??)" wrote:. > >> > > > >> > > Re-post this RFR with correct enhancement number to make it trackable. > >> > > please ignore the previous wrong post. sorry for troubles. > >> > > > >> > > webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/ > >> > > Hi bug: https://bugs.openjdk.java.net/browse/JDK-8215624 > >> > > CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 > >> > > -------------- > >> > > Lin > >> > > >Hi Lin, > > > > > > > >> > > >Could you, please, re-post your RFR with the right enhancement number in > >> > > >the message subject? > >> > > >It will be more trackable this way. > >> > > > > >> > > >Thanks, > >> > > >Serguei > >> > > > > >> > > > > >> > > >On 2/17/20 10:29 PM, linzang(??) wrote: > >> > > >> Dear David, > >> > > >> Thanks a lot! > >> > > >> I have updated the refined code to http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_01/. > >> > > >> IMHO the parallel heap inspection can be extended to all kinds of heap as long as the heap layout can support parallel iteration. > >> > > >> Maybe we can firstly use this webrev to discuss how to implement it, because I am not sure my current implementation is an appropriate way to communicate with collectedHeap, then we can extend the solution to other kinds of heap. > >> > > >> > >> > > >> Thanks, > >> > > >> -------------- > >> > > >> Lin > >> > > >>> Hi Lin, > >> > > >>> > >> > > >>> Adding in hotspot-gc-dev as they need to see how this interacts with GC > >> > > >>> worker threads, and whether it needs to be extended beyond G1. > >> > > >>> > >> > > >>> I happened to spot one nit when browsing: > >> > > >>> > >> > > >>> src/hotspot/share/gc/shared/collectedHeap.hpp > >> > > >>> > >> > > >>> + virtual bool run_par_heap_inspect_task(KlassInfoTable* cit, > >> > > >>> + BoolObjectClosure* filter, > >> > > >>> + size_t* missed_count, > >> > > >>> + size_t thread_num) { > >> > > >>> + return NULL; > >> > > >>> > >> > > >>> s/NULL/false/ > >> > > >>> > >> > > >>> Cheers, > >> > > >>> David > > > > > >>> > >> > > >>> On 18/02/2020 2:15 pm, linzang(??) wrote: > >> > > >>>> Dear All, > >> > > >>>> May I ask your help to review the follow changes: > >> > > >>>> webrev: > >> > > >>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_00/ > >> > > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 > >> > > >>>> related CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 > >> > > >>>> This patch enable parallel heap inspection of G1 for jmap histo. > >> > > >>>> my simple test shown it can speed up 2x of jmap -histo with > >> > > >>>> parallelThreadNum set to 2 for heap at ~500M on 4-core platform. > >> > > >>>> > >> > > >>>> ------------------------------------------------------------------------ > >> > > >>>> BRs, > >> > > >>>> Lin > >> > > >> > > >> > > > > > > > > > > > > > > > From david.holmes at oracle.com Mon Apr 27 05:15:59 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Apr 2020 15:15:59 +1000 Subject: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant In-Reply-To: References: <3c59b9f9-ec38-18c9-8f24-e1186a08a04a@oracle.com> <410eed04-e2ef-0f4f-1c56-19e6734a10f6@oracle.com> <81d7caa8-4244-85f3-4d4e-78117fe5e25b@oss.nttdata.com> Message-ID: <550b95ac-8b29-1eb8-a507-533e81d02322@oracle.com> Hi all, Not a review but some general commentary ... On 25/04/2020 2:08 am, Reingruber, Richard wrote: > Hi Yasumasa, Patricio, > >>>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>>> Does it help you? I think it gives you to remove workaround. >>> >>> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >>> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. > >> Thanks for your information. >> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. >> I will modify and will test it after yours. > > Thanks :) > >>> Also my first impression was that it won't be that easy from a synchronization point of view to >>> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >>> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >>> to me, how this has to be handled. > >> I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. > > Yes. To me it is unclear what synchronization is necessary, if it is called during a handshake. And > also I'm unsure if a thread should do safepoint checks while executing a handshake. I'm growing increasingly concerned that use of direct handshakes to replace VM operations needs a much greater examination for correctness than might initially be thought. I see a number of issues: First, the VMThread executes (most) VM operations with a clean stack in a clean state, so it has lots of room to work. If we now execute the same logic in a JavaThread then we risk hitting stackoverflows if nothing else. But we are also now executing code in a JavaThread and so we have to be sure that code is not going to act differently (in a bad way) if executed by a JavaThread rather than the VMThread. For example, may it be possible that if executing in the VMThread we defer some activity that might require execution of Java code, or else hand it off to one of the service threads? If we execute that code directly in the current JavaThread instead we may not be in a valid state (e.g. consider re-entrancy to various subsystems that is not allowed). Second, we have this question mark over what happens if the operation hits further safepoint or handshake polls/checks? Are there constraints on what is allowed here? How can we recognise this problem may exist and so deal with it? Third, while we are generally considering what appear to be single-thread operations, which should be amenable to a direct handshake, we also have to be careful that some of the code involved doesn't already expect/assume we are at a safepoint - e.g. a VM op may not need to take a lock where a direct handshake might! Cheers, David ----- > @Patricio, coming back to my question [1]: > > In the example you gave in your answer [2]: the java thread would execute a vm operation during a > direct handshake operation, while the VMThread is actually in the middle of a VM_HandshakeAllThreads > operation, waiting to handshake the same handshakee: why can't the VMThread just proceed? The > handshakee would be safepoint safe, wouldn't it? > > Thanks, Richard. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301677&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301677 > > [2] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301763&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301763 > > -----Original Message----- > From: Yasumasa Suenaga > Sent: Freitag, 24. April 2020 17:23 > To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Richard, > > On 2020/04/24 23:44, Reingruber, Richard wrote: >> Hi Yasumasa, >> >>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>> Does it help you? I think it gives you to remove workaround. >> >> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. > > Thanks for your information. > I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. > I will modify and will test it after yours. > > >> Also my first impression was that it won't be that easy from a synchronization point of view to >> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >> to me, how this has to be handled. > > I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. > > > Thanks, > > Yasumasa > > >> So it appears to me that it would be easier to push JDK-8242427 after this (JDK-8238585). >> >>> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >> >> Would be interesting to see how you handled the issues above :) >> >> Thanks, Richard. >> >> [1] See question in comment https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030 >> >> -----Original Message----- >> From: Yasumasa Suenaga >> Sent: Freitag, 24. April 2020 13:34 >> To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Richard, >> >> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >> Does it help you? I think it gives you to remove workaround. >> >> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/24 17:18, Reingruber, Richard wrote: >>> Hi Patricio, Vladimir, and Serguei, >>> >>> now that direct handshakes are available, I've updated the patch to make use of them. >>> >>> In addition I have done some clean-up changes I missed in the first webrev. >>> >>> Finally I have implemented the workaround suggested by Patricio to avoid nesting the handshake >>> into the vm operation VM_SetFramePop [1] >>> >>> Kindly review again: >>> >>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ >>> Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ >>> >>> I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode can be replaced with a >>> direct handshake: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238585 >>> >>> Testing: >>> >>> * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>> >>> * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737 >>> >>> Thanks, >>> Richard. >>> >>> [1] An assertion in Handshake::execute_direct() fails, if called be VMThread, because it is no JavaThread. >>> >>> -----Original Message----- >>> From: hotspot-dev On Behalf Of Reingruber, Richard >>> Sent: Freitag, 14. Februar 2020 19:47 >>> To: Patricio Chilano ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Patricio, >>> >>> > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>> > > handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>> > > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>> > > >>> > > > Alternatively I think you could do something similar to what we do in >>> > > > Deoptimization::deoptimize_all_marked(): >>> > > > >>> > > > EnterInterpOnlyModeClosure hs; >>> > > > if (SafepointSynchronize::is_at_safepoint()) { >>> > > > hs.do_thread(state->get_thread()); >>> > > > } else { >>> > > > Handshake::execute(&hs, state->get_thread()); >>> > > > } >>> > > > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>> > > > HandshakeClosure() constructor) >>> > > >>> > > Maybe this could be used also in the Handshake::execute() methods as general solution? >>> > Right, we could also do that. Avoiding to clear the polling page in >>> > HandshakeState::clear_handshake() should be enough to fix this issue and >>> > execute a handshake inside a safepoint, but adding that "if" statement >>> > in Hanshake::execute() sounds good to avoid all the extra code that we >>> > go through when executing a handshake. I filed 8239084 to make that change. >>> >>> Thanks for taking care of this and creating the RFE. >>> >>> > >>> > > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>> > > > always called in a nested operation or just sometimes. >>> > > >>> > > At least one execution path without vm operation exists: >>> > > >>> > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>> > > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>> > > JvmtiEventControllerPrivate::recompute_enabled() : void >>> > > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>> > > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>> > > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>> > > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>> > > >>> > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>> > > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>> > > encouraged to do it with a handshake :) >>> > Ah! I think you can still do it with a handshake with the >>> > Deoptimization::deoptimize_all_marked() like solution. I can change the >>> > if-else statement with just the Handshake::execute() call in 8239084. >>> > But up to you. : ) >>> >>> Well, I think that's enough encouragement :) >>> I'll wait for 8239084 and try then again. >>> (no urgency and all) >>> >>> Thanks, >>> Richard. >>> >>> -----Original Message----- >>> From: Patricio Chilano >>> Sent: Freitag, 14. Februar 2020 15:54 >>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Richard, >>> >>> On 2/14/20 9:58 AM, Reingruber, Richard wrote: >>>> Hi Patricio, >>>> >>>> thanks for having a look. >>>> >>>> > I?m only commenting on the handshake changes. >>>> > I see that operation VM_EnterInterpOnlyMode can be called inside >>>> > operation VM_SetFramePop which also allows nested operations. Here is a >>>> > comment in VM_SetFramePop definition: >>>> > >>>> > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>> > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>> > >>>> > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>> > could have a handshake inside a safepoint operation. The issue I see >>>> > there is that at the end of the handshake the polling page of the target >>>> > thread could be disarmed. So if the target thread happens to be in a >>>> > blocked state just transiently and wakes up then it will not stop for >>>> > the ongoing safepoint. Maybe I can file an RFE to assert that the >>>> > polling page is armed at the beginning of disarm_safepoint(). >>>> >>>> I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>>> handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>>> Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>>> >>>> > Alternatively I think you could do something similar to what we do in >>>> > Deoptimization::deoptimize_all_marked(): >>>> > >>>> > EnterInterpOnlyModeClosure hs; >>>> > if (SafepointSynchronize::is_at_safepoint()) { >>>> > hs.do_thread(state->get_thread()); >>>> > } else { >>>> > Handshake::execute(&hs, state->get_thread()); >>>> > } >>>> > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>> > HandshakeClosure() constructor) >>>> >>>> Maybe this could be used also in the Handshake::execute() methods as general solution? >>> Right, we could also do that. Avoiding to clear the polling page in >>> HandshakeState::clear_handshake() should be enough to fix this issue and >>> execute a handshake inside a safepoint, but adding that "if" statement >>> in Hanshake::execute() sounds good to avoid all the extra code that we >>> go through when executing a handshake. I filed 8239084 to make that change. >>> >>>> > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>> > always called in a nested operation or just sometimes. >>>> >>>> At least one execution path without vm operation exists: >>>> >>>> JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>>> JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>>> JvmtiEventControllerPrivate::recompute_enabled() : void >>>> JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>>> JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>>> JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>>> jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>>> >>>> I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>>> handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>>> encouraged to do it with a handshake :) >>> Ah! I think you can still do it with a handshake with the >>> Deoptimization::deoptimize_all_marked() like solution. I can change the >>> if-else statement with just the Handshake::execute() call in 8239084. >>> But up to you.? : ) >>> >>> Thanks, >>> Patricio >>>> Thanks again, >>>> Richard. >>>> >>>> -----Original Message----- >>>> From: Patricio Chilano >>>> Sent: Donnerstag, 13. Februar 2020 18:47 >>>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>>> >>>> Hi Richard, >>>> >>>> I?m only commenting on the handshake changes. >>>> I see that operation VM_EnterInterpOnlyMode can be called inside >>>> operation VM_SetFramePop which also allows nested operations. Here is a >>>> comment in VM_SetFramePop definition: >>>> >>>> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>> >>>> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>> could have a handshake inside a safepoint operation. The issue I see >>>> there is that at the end of the handshake the polling page of the target >>>> thread could be disarmed. So if the target thread happens to be in a >>>> blocked state just transiently and wakes up then it will not stop for >>>> the ongoing safepoint. Maybe I can file an RFE to assert that the >>>> polling page is armed at the beginning of disarm_safepoint(). >>>> >>>> I think one option could be to remove >>>> SafepointMechanism::disarm_if_needed() in >>>> HandshakeState::clear_handshake() and let each JavaThread disarm itself >>>> for the handshake case. >>>> >>>> Alternatively I think you could do something similar to what we do in >>>> Deoptimization::deoptimize_all_marked(): >>>> >>>> ? EnterInterpOnlyModeClosure hs; >>>> ? if (SafepointSynchronize::is_at_safepoint()) { >>>> ??? hs.do_thread(state->get_thread()); >>>> ? } else { >>>> ??? Handshake::execute(&hs, state->get_thread()); >>>> ? } >>>> (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>> HandshakeClosure() constructor) >>>> >>>> I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>> always called in a nested operation or just sometimes. >>>> >>>> Thanks, >>>> Patricio >>>> >>>> On 2/12/20 7:23 AM, Reingruber, Richard wrote: >>>>> // Repost including hotspot runtime and gc lists. >>>>> // Dean Long suggested to do so, because the enhancement replaces a vm operation >>>>> // with a handshake. >>>>> // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html >>>>> >>>>> Hi, >>>>> >>>>> could I please get reviews for this small enhancement in hotspot's jvmti implementation: >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >>>>> >>>>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to >>>>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. >>>>> >>>>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. >>>>> >>>>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>>>> >>>>> Thanks, Richard. >>>>> >>>>> See also my question if anyone knows a reason for making the compiled methods not_entrant: >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html >>> From richard.reingruber at sap.com Mon Apr 27 14:09:08 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Mon, 27 Apr 2020 14:09:08 +0000 Subject: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant In-Reply-To: <550b95ac-8b29-1eb8-a507-533e81d02322@oracle.com> References: <3c59b9f9-ec38-18c9-8f24-e1186a08a04a@oracle.com> <410eed04-e2ef-0f4f-1c56-19e6734a10f6@oracle.com> <81d7caa8-4244-85f3-4d4e-78117fe5e25b@oss.nttdata.com> <550b95ac-8b29-1eb8-a507-533e81d02322@oracle.com> Message-ID: Hi David, > Not a review but some general commentary ... That's welcome. > On 25/04/2020 2:08 am, Reingruber, Richard wrote: > > Hi Yasumasa, Patricio, > > > >>>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. > >>>> Does it help you? I think it gives you to remove workaround. > >>> > >>> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake > >>> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to > >>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. > > > >> Thanks for your information. > >> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. > >> I will modify and will test it after yours. > > > > Thanks :) > > > >>> Also my first impression was that it won't be that easy from a synchronization point of view to > >>> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls > >>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where > >>> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear > >>> to me, how this has to be handled. > > > >> I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. > > > > Yes. To me it is unclear what synchronization is necessary, if it is called during a handshake. And > > also I'm unsure if a thread should do safepoint checks while executing a handshake. > I'm growing increasingly concerned that use of direct handshakes to > replace VM operations needs a much greater examination for correctness > than might initially be thought. I see a number of issues: I agree. I'll address your concerns in the context of this review thread for JDK-8238585 below. In addition I would suggest to take the general part of the discussion to a dedicated thread or to the review thread for JDK-8242427. I would like to keep this thread closer to its subject. > First, the VMThread executes (most) VM operations with a clean stack in > a clean state, so it has lots of room to work. If we now execute the > same logic in a JavaThread then we risk hitting stackoverflows if > nothing else. But we are also now executing code in a JavaThread and so > we have to be sure that code is not going to act differently (in a bad > way) if executed by a JavaThread rather than the VMThread. For example, > may it be possible that if executing in the VMThread we defer some > activity that might require execution of Java code, or else hand it off > to one of the service threads? If we execute that code directly in the > current JavaThread instead we may not be in a valid state (e.g. consider > re-entrancy to various subsystems that is not allowed). It is not too complex, what EnterInterpOnlyModeClosure::do_thread() is doing. I already added a paragraph to the JBS-Item [1] explaining why the direct handshake is sufficient from a synchronization point of view. Furthermore the stack is walked and the return pc of compiled frames is replaced with the address of the deopt handler. I can't see why this cannot be done with a direct handshake. Something very similar is already done in JavaThread::deoptimize_marked_methods() which is executed as part of an ordinary handshake. The demand on stack-space should be very modest. I would not expect a higher risk for stackoverflow. > Second, we have this question mark over what happens if the operation > hits further safepoint or handshake polls/checks? Are there constraints > on what is allowed here? How can we recognise this problem may exist and > so deal with it? The thread in EnterInterpOnlyModeClosure::do_thread() can't become safepoint/handshake safe. I tested locally test/hotspot/jtreg:vmTestbase_nsk_jvmti with a NoSafepointVerifier. > Third, while we are generally considering what appear to be > single-thread operations, which should be amenable to a direct > handshake, we also have to be careful that some of the code involved > doesn't already expect/assume we are at a safepoint - e.g. a VM op may > not need to take a lock where a direct handshake might! See again my arguments in the JBS item [1]. Thanks, Richard. [1] https://bugs.openjdk.java.net/browse/JDK-8238585 -----Original Message----- From: David Holmes Sent: Montag, 27. April 2020 07:16 To: Reingruber, Richard ; Yasumasa Suenaga ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant Hi all, Not a review but some general commentary ... On 25/04/2020 2:08 am, Reingruber, Richard wrote: > Hi Yasumasa, Patricio, > >>>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>>> Does it help you? I think it gives you to remove workaround. >>> >>> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >>> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. > >> Thanks for your information. >> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. >> I will modify and will test it after yours. > > Thanks :) > >>> Also my first impression was that it won't be that easy from a synchronization point of view to >>> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >>> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >>> to me, how this has to be handled. > >> I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. > > Yes. To me it is unclear what synchronization is necessary, if it is called during a handshake. And > also I'm unsure if a thread should do safepoint checks while executing a handshake. I'm growing increasingly concerned that use of direct handshakes to replace VM operations needs a much greater examination for correctness than might initially be thought. I see a number of issues: First, the VMThread executes (most) VM operations with a clean stack in a clean state, so it has lots of room to work. If we now execute the same logic in a JavaThread then we risk hitting stackoverflows if nothing else. But we are also now executing code in a JavaThread and so we have to be sure that code is not going to act differently (in a bad way) if executed by a JavaThread rather than the VMThread. For example, may it be possible that if executing in the VMThread we defer some activity that might require execution of Java code, or else hand it off to one of the service threads? If we execute that code directly in the current JavaThread instead we may not be in a valid state (e.g. consider re-entrancy to various subsystems that is not allowed). Second, we have this question mark over what happens if the operation hits further safepoint or handshake polls/checks? Are there constraints on what is allowed here? How can we recognise this problem may exist and so deal with it? Third, while we are generally considering what appear to be single-thread operations, which should be amenable to a direct handshake, we also have to be careful that some of the code involved doesn't already expect/assume we are at a safepoint - e.g. a VM op may not need to take a lock where a direct handshake might! Cheers, David ----- > @Patricio, coming back to my question [1]: > > In the example you gave in your answer [2]: the java thread would execute a vm operation during a > direct handshake operation, while the VMThread is actually in the middle of a VM_HandshakeAllThreads > operation, waiting to handshake the same handshakee: why can't the VMThread just proceed? The > handshakee would be safepoint safe, wouldn't it? > > Thanks, Richard. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301677&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301677 > > [2] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301763&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301763 > > -----Original Message----- > From: Yasumasa Suenaga > Sent: Freitag, 24. April 2020 17:23 > To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > > Hi Richard, > > On 2020/04/24 23:44, Reingruber, Richard wrote: >> Hi Yasumasa, >> >>> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >>> Does it help you? I think it gives you to remove workaround. >> >> I think it would not help that much. Note that when replacing VM_SetFramePop with a direct handshake >> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1]. So you would have to >> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these changes. > > Thanks for your information. > I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. > I will modify and will test it after yours. > > >> Also my first impression was that it won't be that easy from a synchronization point of view to >> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() indirectly calls >> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) where >> JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. It's not directly clear >> to me, how this has to be handled. > > I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. > > > Thanks, > > Yasumasa > > >> So it appears to me that it would be easier to push JDK-8242427 after this (JDK-8238585). >> >>> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >> >> Would be interesting to see how you handled the issues above :) >> >> Thanks, Richard. >> >> [1] See question in comment https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030 >> >> -----Original Message----- >> From: Yasumasa Suenaga >> Sent: Freitag, 24. April 2020 13:34 >> To: Reingruber, Richard ; Patricio Chilano ; serguei.spitsyn at oracle.com; Vladimir Ivanov ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >> >> Hi Richard, >> >> I will send review request to replace VM_SetFramePop to handshake in early next week in JDK-8242427. >> Does it help you? I think it gives you to remove workaround. >> >> (The patch is available, but I want to see the result of PIT in this weekend whether JDK-8242425 works fine.) >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/04/24 17:18, Reingruber, Richard wrote: >>> Hi Patricio, Vladimir, and Serguei, >>> >>> now that direct handshakes are available, I've updated the patch to make use of them. >>> >>> In addition I have done some clean-up changes I missed in the first webrev. >>> >>> Finally I have implemented the workaround suggested by Patricio to avoid nesting the handshake >>> into the vm operation VM_SetFramePop [1] >>> >>> Kindly review again: >>> >>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ >>> Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ >>> >>> I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode can be replaced with a >>> direct handshake: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8238585 >>> >>> Testing: >>> >>> * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>> >>> * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737 >>> >>> Thanks, >>> Richard. >>> >>> [1] An assertion in Handshake::execute_direct() fails, if called be VMThread, because it is no JavaThread. >>> >>> -----Original Message----- >>> From: hotspot-dev On Behalf Of Reingruber, Richard >>> Sent: Freitag, 14. Februar 2020 19:47 >>> To: Patricio Chilano ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Patricio, >>> >>> > > I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>> > > handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>> > > Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>> > > >>> > > > Alternatively I think you could do something similar to what we do in >>> > > > Deoptimization::deoptimize_all_marked(): >>> > > > >>> > > > EnterInterpOnlyModeClosure hs; >>> > > > if (SafepointSynchronize::is_at_safepoint()) { >>> > > > hs.do_thread(state->get_thread()); >>> > > > } else { >>> > > > Handshake::execute(&hs, state->get_thread()); >>> > > > } >>> > > > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>> > > > HandshakeClosure() constructor) >>> > > >>> > > Maybe this could be used also in the Handshake::execute() methods as general solution? >>> > Right, we could also do that. Avoiding to clear the polling page in >>> > HandshakeState::clear_handshake() should be enough to fix this issue and >>> > execute a handshake inside a safepoint, but adding that "if" statement >>> > in Hanshake::execute() sounds good to avoid all the extra code that we >>> > go through when executing a handshake. I filed 8239084 to make that change. >>> >>> Thanks for taking care of this and creating the RFE. >>> >>> > >>> > > > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>> > > > always called in a nested operation or just sometimes. >>> > > >>> > > At least one execution path without vm operation exists: >>> > > >>> > > JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>> > > JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>> > > JvmtiEventControllerPrivate::recompute_enabled() : void >>> > > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>> > > JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>> > > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>> > > jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>> > > >>> > > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>> > > handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>> > > encouraged to do it with a handshake :) >>> > Ah! I think you can still do it with a handshake with the >>> > Deoptimization::deoptimize_all_marked() like solution. I can change the >>> > if-else statement with just the Handshake::execute() call in 8239084. >>> > But up to you. : ) >>> >>> Well, I think that's enough encouragement :) >>> I'll wait for 8239084 and try then again. >>> (no urgency and all) >>> >>> Thanks, >>> Richard. >>> >>> -----Original Message----- >>> From: Patricio Chilano >>> Sent: Freitag, 14. Februar 2020 15:54 >>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>> >>> Hi Richard, >>> >>> On 2/14/20 9:58 AM, Reingruber, Richard wrote: >>>> Hi Patricio, >>>> >>>> thanks for having a look. >>>> >>>> > I?m only commenting on the handshake changes. >>>> > I see that operation VM_EnterInterpOnlyMode can be called inside >>>> > operation VM_SetFramePop which also allows nested operations. Here is a >>>> > comment in VM_SetFramePop definition: >>>> > >>>> > // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>> > // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>> > >>>> > So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>> > could have a handshake inside a safepoint operation. The issue I see >>>> > there is that at the end of the handshake the polling page of the target >>>> > thread could be disarmed. So if the target thread happens to be in a >>>> > blocked state just transiently and wakes up then it will not stop for >>>> > the ongoing safepoint. Maybe I can file an RFE to assert that the >>>> > polling page is armed at the beginning of disarm_safepoint(). >>>> >>>> I'm really glad you noticed the problematic nesting. This seems to be a general issue: currently a >>>> handshake cannot be nested in a vm operation. Maybe it should be asserted in the >>>> Handshake::execute() methods that they are not called by the vm thread evaluating a vm operation? >>>> >>>> > Alternatively I think you could do something similar to what we do in >>>> > Deoptimization::deoptimize_all_marked(): >>>> > >>>> > EnterInterpOnlyModeClosure hs; >>>> > if (SafepointSynchronize::is_at_safepoint()) { >>>> > hs.do_thread(state->get_thread()); >>>> > } else { >>>> > Handshake::execute(&hs, state->get_thread()); >>>> > } >>>> > (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>> > HandshakeClosure() constructor) >>>> >>>> Maybe this could be used also in the Handshake::execute() methods as general solution? >>> Right, we could also do that. Avoiding to clear the polling page in >>> HandshakeState::clear_handshake() should be enough to fix this issue and >>> execute a handshake inside a safepoint, but adding that "if" statement >>> in Hanshake::execute() sounds good to avoid all the extra code that we >>> go through when executing a handshake. I filed 8239084 to make that change. >>> >>>> > I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>> > always called in a nested operation or just sometimes. >>>> >>>> At least one execution path without vm operation exists: >>>> >>>> JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void >>>> JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) : jlong >>>> JvmtiEventControllerPrivate::recompute_enabled() : void >>>> JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) : void (2 matches) >>>> JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void >>>> JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError >>>> jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) : jvmtiError >>>> >>>> I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to replace it with a >>>> handshake, but to avoid making the compiled methods on stack not_entrant.... unless I'm further >>>> encouraged to do it with a handshake :) >>> Ah! I think you can still do it with a handshake with the >>> Deoptimization::deoptimize_all_marked() like solution. I can change the >>> if-else statement with just the Handshake::execute() call in 8239084. >>> But up to you.? : ) >>> >>> Thanks, >>> Patricio >>>> Thanks again, >>>> Richard. >>>> >>>> -----Original Message----- >>>> From: Patricio Chilano >>>> Sent: Donnerstag, 13. Februar 2020 18:47 >>>> To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net >>>> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant >>>> >>>> Hi Richard, >>>> >>>> I?m only commenting on the handshake changes. >>>> I see that operation VM_EnterInterpOnlyMode can be called inside >>>> operation VM_SetFramePop which also allows nested operations. Here is a >>>> comment in VM_SetFramePop definition: >>>> >>>> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is >>>> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled. >>>> >>>> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we >>>> could have a handshake inside a safepoint operation. The issue I see >>>> there is that at the end of the handshake the polling page of the target >>>> thread could be disarmed. So if the target thread happens to be in a >>>> blocked state just transiently and wakes up then it will not stop for >>>> the ongoing safepoint. Maybe I can file an RFE to assert that the >>>> polling page is armed at the beginning of disarm_safepoint(). >>>> >>>> I think one option could be to remove >>>> SafepointMechanism::disarm_if_needed() in >>>> HandshakeState::clear_handshake() and let each JavaThread disarm itself >>>> for the handshake case. >>>> >>>> Alternatively I think you could do something similar to what we do in >>>> Deoptimization::deoptimize_all_marked(): >>>> >>>> ? EnterInterpOnlyModeClosure hs; >>>> ? if (SafepointSynchronize::is_at_safepoint()) { >>>> ??? hs.do_thread(state->get_thread()); >>>> ? } else { >>>> ??? Handshake::execute(&hs, state->get_thread()); >>>> ? } >>>> (you could pass ?EnterInterpOnlyModeClosure? directly to the >>>> HandshakeClosure() constructor) >>>> >>>> I don?t know JVMTI code so I?m not sure if VM_EnterInterpOnlyMode is >>>> always called in a nested operation or just sometimes. >>>> >>>> Thanks, >>>> Patricio >>>> >>>> On 2/12/20 7:23 AM, Reingruber, Richard wrote: >>>>> // Repost including hotspot runtime and gc lists. >>>>> // Dean Long suggested to do so, because the enhancement replaces a vm operation >>>>> // with a handshake. >>>>> // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html >>>>> >>>>> Hi, >>>>> >>>>> could I please get reviews for this small enhancement in hotspot's jvmti implementation: >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >>>>> >>>>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to >>>>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. >>>>> >>>>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. >>>>> >>>>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. >>>>> >>>>> Thanks, Richard. >>>>> >>>>> See also my question if anyone knows a reason for making the compiled methods not_entrant: >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html >>> From stefan.karlsson at oracle.com Mon Apr 27 16:22:25 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 27 Apr 2020 18:22:25 +0200 Subject: RFR(S/T) : 8243568 : serviceability/logging/TestLogRotation.java uses 'test.java.opts' and not 'test.vm.opts' In-Reply-To: <5C0211CA-0541-4739-B6E4-00A7DA7A22FF@oracle.com> References: <5C0211CA-0541-4739-B6E4-00A7DA7A22FF@oracle.com> Message-ID: <2ffdb0a9-9f27-d227-8b4b-18fecf7f24e4@oracle.com> Looks good. StefanK On 2020-04-25 00:30, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 >> 8 lines changed: 0 ins; 6 del; 2 mod; > Hi all, > > could you please review this small and trivial patch which updates serviceability/logging/TestLogRotation.java test to pass both 'test.java.opts' and not 'test.vm.opts' ? to do that, the patch removes the custom logic of handling test.java.opts and just uses ProcessTools.createJavaProcessBuilder(boolean addTestVmAndJavaOptions=true, String...), which prepends values of both properties. > from JBS: >> serviceability/logging/TestLogRotation.java test use 'test.java.opts' to get external vm flags, yet actually external flags are split b/w 'test.java.opts' and 'test.vm.opts' and in the majority of cases all external flags are set listed in 'test.vm.opts' so the test should be updated to read both. > JBS: https://bugs.openjdk.java.net/browse/JDK-8243568 > webrev: http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00 > > Thanks, > -- Igor From daniil.x.titov at oracle.com Mon Apr 27 19:07:04 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 27 Apr 2020 12:07:04 -0700 Subject: RFR: 8242009: Review setting test.java/vm.opts in jcmd/jhsdb and debugger in serviceability tests Message-ID: <8A7DC761-66F8-4AB2-AE46-B8C41C964859@oracle.com> Please review the change [1] that ensures that VM and test options are forwarded to j*-tools when they are launched from serviceability/sa tests. The tests that expect an empty output were corrected to ignore the product version printed in the error stream since in some tiers the tests are run with ' -showversion' VM option (tier3). In test serviceability/sa/TestSysProps.java the code that counts the system properties was corrected to ignore the debug output when the test is run with " -Xlog:cds=debug" option (tier4). Testing: Mach5 tests for tier1 - tier7 passed. I also run the test with -XComp at Mach5 linux-x64-debug builds before and after the changes and for the most of the tests the overhead is about 2 times although for serviceability/sa/sadebugd/SADebugDTest.java it spikes up to 5 times. Probably at least for some tests it makes to filter out some properties (e.g. -Xcomp) before forwarding them to j*-tools. serviceability/sa/sadebugd/SADebugDTest.java, before : 2m 23s , after:11m 07s serviceability/sa/sadebugd/TestJmapCore.java, before : 42s , after:1m 09s serviceability/sa/TestSysProps.java, before : 36s , after: 1m 27s [1] http://cr.openjdk.java.net/~dtitov/8242009/webrev.01 [2] https://bugs.openjdk.java.net/browse/JDK-8242009 Thank you, Daniil From chris.plummer at oracle.com Mon Apr 27 19:12:12 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 27 Apr 2020 12:12:12 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same In-Reply-To: References: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> <9deb907b-0cbb-2a05-73a3-1aa4c6f5fc94@oracle.com> <9523cda9-66a0-e609-f199-117f02d907d7@oracle.com> <1F96342D-332B-4ABE-9BCC-952969421805@oracle.com> <0df530e0-0ef7-10cd-7226-c6ebbca7654f@oracle.com> Message-ID: Hi Daniil, ? 83???????????? // names2, and names3 will have different size. Repeat the test in this case. Should be "sizes". There are a few instances of this in the comments that need to be changed. Looks good otherwise. I don't need to see another webrev. thanks, Chris On 4/25/20 9:11 AM, Daniil Titov wrote: > Hi Serguei, > > Please review a new version of the webrev [1] that changes the condition > as you suggested. Please note then in both cases we need break from the loop : the case when > it is a first attempt and the conditions are met and the case when it is a second attempt. > > > [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.03 > [2] https://bugs.openjdk.java.net/browse/JDK-8242239 > > Thank you, > Daniil > > > From: "serguei.spitsyn at oracle.com" > Date: Saturday, April 25, 2020 at 12:06 AM > To: Daniil Titov , Chris Plummer , serviceability-dev > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Daniil, > > Thank you for the update. > > On 4/24/20 22:22, Daniil Titov wrote: > Hi Chris and Serguei, > > Please review a new version of the fix [1] that makes the tests try to repeat the check only once. > > Regarding the question Serguei asked: > > 97 while(true) { > 113 if (mbeanCount * 2 == counterCount || isSecondAttempt) { > 114 assertEquals(mbeanCount * 2, counterCount); > I doubt, the assert is really needed. > we need the assert here to make the test fail in case if it is a second attempt and the conditions are not met. > > A space is still needed in "while(true)." > 111 if (mbeanCount * 2 == counterCount || isSecondAttempt) { > 112 assertEquals(mbeanCount * 2, counterCount); > 113 break; > 114 } > The code above is a little confusing as we have to logically separate the assert and break cases. > Would something like below be more straightforward?: > ???? if (mbeanCount * 2 == counterCount) { > ???????? break; > ???? } > ???? if (isSecondAttempt) { > ? ? ? ?? assertEquals(mbeanCount * 2 != counterCount); > ???? } > > Otherwise, the update looks good. > > Thanks, > Serguei > > > [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.02/ > [2] https://bugs.openjdk.java.net/browse/JDK-8242239 > > Thank you, > Daniil > > > From: serviceability-dev mailto:serviceability-dev-bounces at openjdk.java.net on behalf of Daniil Titov mailto:daniil.x.titov at oracle.com > Date: Friday, April 24, 2020 at 2:08 PM > To: Chris Plummer mailto:chris.plummer at oracle.com, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Chris, > > I agree with you. I will change the test to retry just once. > > Thank you, > Daniil > > > From: Chris Plummer mailto:chris.plummer at oracle.com > Date: Friday, April 24, 2020 at 1:27 PM > To: Daniil Titov mailto:daniil.x.titov at oracle.com, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Daniil, > > I think a retry count more in line with our current expectations would make more sense since it is deterministic how many retries are might actually be needed. You just used a large number in case more ?lazy-registered? mbeans are added in the future, but if this is the case then maybe even 10 is not enough. > > thanks, > > Chris > > On 4/24/20 12:36 PM, Daniil Titov wrote: > Hi Serguei and Chris, > > Thank you for your comments. > > I wanted to make the fix ?more generic ?and not limit it just to Graal management bean. In this case we could expect that after the first retry is triggered by Graal MBean registration some other ?lazy-registered? MBean got registered and the test might fail. To avoid this we need to allow test to make at least several retry attempts before failing.? If number 10 looks as too high we could make it 5 or even 3. This should not affect the test run-time unless the test starts failing for some other reason than we expect. ?In the new webrev I will also correct ?the iteration counting (as Chris mentioned) and fix typos. > > Thanks again, > Daniil > > From: mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com > Date: Friday, April 24, 2020 at 11:48 AM > To: Chris Plummer mailto:chris.plummer at oracle.com, Daniil Titov mailto:daniil.x.titov at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Daniil, > > Besides what Chris is pointed out the fix looks good. > > Minor: > ? 97???????? while(true) { > 113???????????? if(mbeanCount * 2 == counterCount || retryCounter++ > MAX_RETRY_ATTEMPT) { > 114???????????????? assertEquals(mbeanCount * 2, counterCount); > ?Space is missed in while and if. > ?I doubt, the assert is really needed. > ? 96???????? // is running ( e.g. Graal MBean). In this case just retry the test. > ?Extra space before "e.g.". > > Thanks, > Serguei > > > On 4/24/20 11:30, Chris Plummer wrote: > Hi Daniil, > > ? 84???????????? // If new MBean (e.g. Graal MBean) is registred while the test is running names1, > ?106???????????? // If new MBean (e.g. Graal MBean) is registred while the test is running mbeans1, > > registred -> registered > ',' after "running" > > Just wondering how you chose 10 as the number of retries. Seems excessive. Shouldn't the problem turn up at most 1 time and therefore only 1 retry is needed. > > ? 76???????? int counter = 0; > ? 86???????????? if (sameSize(names1, names2, names3) || counter++ > MAX_RETRY_ATTEMPTS) { > > The way the checks are done you will actually end up retrying MAX_RETRY_ATTEMPTS+1 times. For example, if MAX_RETRY_ATTEMPTS is 1, first time through the loop counter is 0 so a retry is allowed. Second time through the loop counter is 1, so a retry is allowed again. > > thanks, > > Chris > > On 4/18/20 11:30 AM, Daniil Titov wrote: > > > > Please review the change that fixes the failure of javax/management/generified/GenericTest.java? and > ? javax/management/query/CustomQueryTest.java tests when Graal is on. > > The tests checks that calls of management API are consistent and return the same set of MBeans.? However, > when Graal is on the Graal MBean might be registered between the calls that in turn makes the results > inconsistent and the tests fail. > > The fix makes the test aware that some MBean might be registered while the checks run and if it happens the tests repeat the check. > > Testing : Mach5 tests with Graal on and tier1-tier3 tests passed. > > [1]? http://cr.openjdk.java.net/~dtitov/8242239/webrev.01/ > [2] https://bugs.openjdk.java.net/browse/JDK-8242239 > > Thanks, > Daniil > > > > > > > > > > > > > > > > > > > From chris.plummer at oracle.com Mon Apr 27 19:16:48 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 27 Apr 2020 12:16:48 -0700 Subject: Fwd: RFR(S) 8231634: SA stack walking fails with "illegal bci" In-Reply-To: <8d9be633-2b65-a9b1-ddc1-ac89cf560474@oracle.com> References: <8d9be633-2b65-a9b1-ddc1-ac89cf560474@oracle.com> Message-ID: <62ffb3e0-242b-9210-662a-14a0f112e9a2@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Apr 27 19:17:29 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 27 Apr 2020 12:17:29 -0700 Subject: RFR(M) 8243500: SA: Incorrect BCI and Line Number with jstack if the top frame is in the interpreter (BSD and Windows) In-Reply-To: <02c3237c-8890-7c10-530b-5a6b52684126@oracle.com> References: <02c3237c-8890-7c10-530b-5a6b52684126@oracle.com> Message-ID: <1566d163-631f-cb3c-3f75-0bcc230c38be@oracle.com> Ping! Please help review if you can. thanks, Chris On 4/24/20 12:44 AM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8243500 > http://cr.openjdk.java.net/~cjplummer/8243500/webrev.00/index.html > > A couple years ago JDK-8214226 fixed an issue on Linux-x64 with SA > stack dumps not properly displaying the correct line number for the > topmost frame if it was interpreted. The issue was that SA was always > relying on frame->bcp when in fact the BCP is kept in R13, and only > flushed to frame->bcp when needed as a scratch register. So this means > that SA was in most cases grabbing a stale value from frame->bcp. > > The fix for JDK-8214226 was mostly made in X86Frame.java to support > using the BCP register for the topmost frame instead using frame->bcp. > This fix actually had a bug in it that was causing the "illegal bci" > failures we've been seeing. There is already a separate webrev and RFR > out for that: > > https://bugs.openjdk.java.net/browse/JDK-8231634 > http://cr.openjdk.java.net/~cjplummer/8231634/webrev.00/index.html > > What this RFR addresses is the fact that part of the fix for > JDK-8214226 was in LinuxAMD64JavaThreadPDAccess.java, but the same > changes were never made to WindowsAMD64JavaThreadPDAccess.java or > BsdAMD64JavaThreadPDAccess.java. This fix addresses those two ports. > Here's the CR and changeset for reference: > > https://bugs.openjdk.java.net/browse/JDK-8214226 > http://hg.openjdk.java.net/jdk/jdk/rev/9a73a4e4011f > > The changes for the fix are pretty trivial. The more complicated part > is the test I added that will reproduce the issue 100% of the time on > platforms where SA does not properly check the BCP register. For this > reason I've used @requires to limit running this test on just those > platforms I know have the support in place. The test has pretty good > comments on how it works, so I won't go into details here. > > thanks, > > Chris From daniil.x.titov at oracle.com Mon Apr 27 19:37:08 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 27 Apr 2020 12:37:08 -0700 Subject: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same In-Reply-To: References: <34BE518A-AFC2-4AEF-8111-4A58C4FB48A7@oracle.com> <9deb907b-0cbb-2a05-73a3-1aa4c6f5fc94@oracle.com> <9523cda9-66a0-e609-f199-117f02d907d7@oracle.com> <1F96342D-332B-4ABE-9BCC-952969421805@oracle.com> <0df530e0-0ef7-10cd-7226-c6ebbca7654f@oracle.com> Message-ID: <35BEAC7E-F4D0-4C5A-B19F-CB21738B9283@oracle.com> Thank you, Chris and Serguei, for reviewing this change. I will fix typos before pushing in the repository. Best regards, Daniil ?On 4/27/20, 12:12 PM, "Chris Plummer" wrote: Hi Daniil, 83 // names2, and names3 will have different size. Repeat the test in this case. Should be "sizes". There are a few instances of this in the comments that need to be changed. Looks good otherwise. I don't need to see another webrev. thanks, Chris On 4/25/20 9:11 AM, Daniil Titov wrote: > Hi Serguei, > > Please review a new version of the webrev [1] that changes the condition > as you suggested. Please note then in both cases we need break from the loop : the case when > it is a first attempt and the conditions are met and the case when it is a second attempt. > > > [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.03 > [2] https://bugs.openjdk.java.net/browse/JDK-8242239 > > Thank you, > Daniil > > > From: "serguei.spitsyn at oracle.com" > Date: Saturday, April 25, 2020 at 12:06 AM > To: Daniil Titov , Chris Plummer , serviceability-dev > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Daniil, > > Thank you for the update. > > On 4/24/20 22:22, Daniil Titov wrote: > Hi Chris and Serguei, > > Please review a new version of the fix [1] that makes the tests try to repeat the check only once. > > Regarding the question Serguei asked: > > 97 while(true) { > 113 if (mbeanCount * 2 == counterCount || isSecondAttempt) { > 114 assertEquals(mbeanCount * 2, counterCount); > I doubt, the assert is really needed. > we need the assert here to make the test fail in case if it is a second attempt and the conditions are not met. > > A space is still needed in "while(true)." > 111 if (mbeanCount * 2 == counterCount || isSecondAttempt) { > 112 assertEquals(mbeanCount * 2, counterCount); > 113 break; > 114 } > The code above is a little confusing as we have to logically separate the assert and break cases. > Would something like below be more straightforward?: > if (mbeanCount * 2 == counterCount) { > break; > } > if (isSecondAttempt) { > assertEquals(mbeanCount * 2 != counterCount); > } > > Otherwise, the update looks good. > > Thanks, > Serguei > > > [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.02/ > [2] https://bugs.openjdk.java.net/browse/JDK-8242239 > > Thank you, > Daniil > > > From: serviceability-dev mailto:serviceability-dev-bounces at openjdk.java.net on behalf of Daniil Titov mailto:daniil.x.titov at oracle.com > Date: Friday, April 24, 2020 at 2:08 PM > To: Chris Plummer mailto:chris.plummer at oracle.com, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Chris, > > I agree with you. I will change the test to retry just once. > > Thank you, > Daniil > > > From: Chris Plummer mailto:chris.plummer at oracle.com > Date: Friday, April 24, 2020 at 1:27 PM > To: Daniil Titov mailto:daniil.x.titov at oracle.com, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Daniil, > > I think a retry count more in line with our current expectations would make more sense since it is deterministic how many retries are might actually be needed. You just used a large number in case more ?lazy-registered? mbeans are added in the future, but if this is the case then maybe even 10 is not enough. > > thanks, > > Chris > > On 4/24/20 12:36 PM, Daniil Titov wrote: > Hi Serguei and Chris, > > Thank you for your comments. > > I wanted to make the fix more generic and not limit it just to Graal management bean. In this case we could expect that after the first retry is triggered by Graal MBean registration some other ?lazy-registered? MBean got registered and the test might fail. To avoid this we need to allow test to make at least several retry attempts before failing. If number 10 looks as too high we could make it 5 or even 3. This should not affect the test run-time unless the test starts failing for some other reason than we expect. In the new webrev I will also correct the iteration counting (as Chris mentioned) and fix typos. > > Thanks again, > Daniil > > From: mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com > Date: Friday, April 24, 2020 at 11:48 AM > To: Chris Plummer mailto:chris.plummer at oracle.com, Daniil Titov mailto:daniil.x.titov at oracle.com, serviceability-dev mailto:serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same > > Hi Daniil, > > Besides what Chris is pointed out the fix looks good. > > Minor: > 97 while(true) { > 113 if(mbeanCount * 2 == counterCount || retryCounter++ > MAX_RETRY_ATTEMPT) { > 114 assertEquals(mbeanCount * 2, counterCount); > Space is missed in while and if. > I doubt, the assert is really needed. > 96 // is running ( e.g. Graal MBean). In this case just retry the test. > Extra space before "e.g.". > > Thanks, > Serguei > > > On 4/24/20 11:30, Chris Plummer wrote: > Hi Daniil, > > 84 // If new MBean (e.g. Graal MBean) is registred while the test is running names1, > 106 // If new MBean (e.g. Graal MBean) is registred while the test is running mbeans1, > > registred -> registered > ',' after "running" > > Just wondering how you chose 10 as the number of retries. Seems excessive. Shouldn't the problem turn up at most 1 time and therefore only 1 retry is needed. > > 76 int counter = 0; > 86 if (sameSize(names1, names2, names3) || counter++ > MAX_RETRY_ATTEMPTS) { > > The way the checks are done you will actually end up retrying MAX_RETRY_ATTEMPTS+1 times. For example, if MAX_RETRY_ATTEMPTS is 1, first time through the loop counter is 0 so a retry is allowed. Second time through the loop counter is 1, so a retry is allowed again. > > thanks, > > Chris > > On 4/18/20 11:30 AM, Daniil Titov wrote: > > > > Please review the change that fixes the failure of javax/management/generified/GenericTest.java and > javax/management/query/CustomQueryTest.java tests when Graal is on. > > The tests checks that calls of management API are consistent and return the same set of MBeans. However, > when Graal is on the Graal MBean might be registered between the calls that in turn makes the results > inconsistent and the tests fail. > > The fix makes the test aware that some MBean might be registered while the checks run and if it happens the tests repeat the check. > > Testing : Mach5 tests with Graal on and tier1-tier3 tests passed. > > [1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.01/ > [2] https://bugs.openjdk.java.net/browse/JDK-8242239 > > Thanks, > Daniil > > > > > > > > > > > > > > > > > > > From chris.plummer at oracle.com Mon Apr 27 19:55:06 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 27 Apr 2020 12:55:06 -0700 Subject: RFR: 8242009: Review setting test.java/vm.opts in jcmd/jhsdb and debugger in serviceability tests In-Reply-To: <8A7DC761-66F8-4AB2-AE46-B8C41C964859@oracle.com> References: <8A7DC761-66F8-4AB2-AE46-B8C41C964859@oracle.com> Message-ID: Hi Daniil, Overall it looks good. A few comments below. Can you add a comment to TestSysProps.java indicating the reason for checking if the line starts with "[". In JDKToolLauncher you have an extra empty line: ?112????? * Any platform specific arguments required for running the tool are ?113????? * automatically added. ?114????? * ?115????? * ?116????? * @param args In OutputAnalyzer.java, I wonder if all these matching APIs you updated should by default just include the version output in their filtering. As for the added time to execute, I would suggest possibly stripping -Xcomp from the few outliers, and I would mostly focus on how much longer it takes, not how many times longer. For example, increasing from 10 seconds to 40 seconds is not a big deal. Increasing from 10 minutes to 20 minutes is. SADebugDTest creates 8 tool processes so, that's probably the reason for the big increase, although I'm not sure why it is kind of slow in the first place. It does nothing more on each iteration than launch "jhsdb debugd", which will connect to the debuggee, and then is killed off. Maybe there is something slow with connecting, especial with RMI. thanks, Chris On 4/27/20 12:07 PM, Daniil Titov wrote: > Please review the change [1] that ensures that VM and test options are forwarded to > j*-tools when they are launched from serviceability/sa tests. > > The tests that expect an empty output were corrected to ignore the product version printed > in the error stream since in some tiers the tests are run with ' -showversion' VM option (tier3). > > In test serviceability/sa/TestSysProps.java the code that counts the system properties was corrected > to ignore the debug output when the test is run with " -Xlog:cds=debug" option (tier4). > > Testing: Mach5 tests for tier1 - tier7 passed. > > I also run the test with -XComp at Mach5 linux-x64-debug builds before and after the changes > and for the most of the tests the overhead is about 2 times although for > serviceability/sa/sadebugd/SADebugDTest.java it spikes up to 5 times. Probably at least for some tests > it makes to filter out some properties (e.g. -Xcomp) before forwarding them to j*-tools. > > serviceability/sa/sadebugd/SADebugDTest.java, before : 2m 23s , after:11m 07s > serviceability/sa/sadebugd/TestJmapCore.java, before : 42s , after:1m 09s > serviceability/sa/TestSysProps.java, before : 36s , after: 1m 27s > > > [1] http://cr.openjdk.java.net/~dtitov/8242009/webrev.01 > [2] https://bugs.openjdk.java.net/browse/JDK-8242009 > > Thank you, > Daniil > > From alexey.menkov at oracle.com Mon Apr 27 21:24:11 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 27 Apr 2020 14:24:11 -0700 Subject: RFR (S): 8242237: Improve JVM TI HiddenClasses tests In-Reply-To: References: <84d00dbf-a6e4-3407-6f8e-f3faa4c92e5c@oracle.com> Message-ID: Hi Serguei, LGTM++ --alex On 04/24/2020 15:20, serguei.spitsyn at oracle.com wrote: > Hi Leonid, > > Thank you for review and suggestion. > Will fix it. > > Thanks, > Serguei > > > On 4/24/20 15:11, Leonid Mesnik wrote: >> Looks good. >> >> The small nit (optional). New function >> 287 static void JNICALL >> 288 ClassPrepare(jvmtiEnv* jvmti, JNIEnv* jni, jthread thread, jclass klass) { >> >> is very similar to?ClassLoad, and verification of signature might be >> moved into common function. >> >> Leonid >> >>> On Apr 24, 2020, at 11:31 AM, serguei.spitsyn at oracle.com >>> wrote: >>> >>> Please, review a fix for the sub-task: >>> https://bugs.openjdk.java.net/browse/JDK-8242237 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/jvmti-hidden-test-update.1/ >>> >>> Summary: >>> ? The test update includes: >>> ?? - interface and method renaming: Test => HCInterf, test() => >>> hcMethod() >>> ?? - readClassFile replaced with Files.readAllBytes >>> ?? - added ClassPrepare event >>> ?? - removed unneeded capability can_get_source_file_name >>> ?? - added more comments >>> >>> Testing: >>> ? Tested locally on Linux, mach5 test run is in progress: >>> https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jvmti-test-20200424-1829-10485216 >>> >>> Thanks, >>> Serguei >>> >> > From serguei.spitsyn at oracle.com Mon Apr 27 21:26:53 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2020 14:26:53 -0700 Subject: RFR (S): 8242237: Improve JVM TI HiddenClasses tests In-Reply-To: References: <84d00dbf-a6e4-3407-6f8e-f3faa4c92e5c@oracle.com> Message-ID: <1e2ce201-abd2-3cba-30fd-8667025de6ea@oracle.com> Thanks a lot, Alex! Serguei On 4/27/20 14:24, Alex Menkov wrote: > Hi Serguei, > > LGTM++ > > --alex > > On 04/24/2020 15:20, serguei.spitsyn at oracle.com wrote: >> Hi Leonid, >> >> Thank you for review and suggestion. >> Will fix it. >> >> Thanks, >> Serguei >> >> >> On 4/24/20 15:11, Leonid Mesnik wrote: >>> Looks good. >>> >>> The small nit (optional). New function >>> ? 287 static void JNICALL >>> ? 288 ClassPrepare(jvmtiEnv* jvmti, JNIEnv* jni, jthread thread, >>> jclass klass) { >>> >>> is very similar to?ClassLoad, and verification of signature might be >>> moved into common function. >>> >>> Leonid >>> >>>> On Apr 24, 2020, at 11:31 AM, serguei.spitsyn at oracle.com >>>> wrote: >>>> >>>> Please, review a fix for the sub-task: >>>> https://bugs.openjdk.java.net/browse/JDK-8242237 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/jvmti-hidden-test-update.1/ >>>> >>>> >>>> Summary: >>>> ? The test update includes: >>>> ?? - interface and method renaming: Test => HCInterf, test() => >>>> hcMethod() >>>> ?? - readClassFile replaced with Files.readAllBytes >>>> ?? - added ClassPrepare event >>>> ?? - removed unneeded capability can_get_source_file_name >>>> ?? - added more comments >>>> >>>> Testing: >>>> ? Tested locally on Linux, mach5 test run is in progress: >>>> https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jvmti-test-20200424-1829-10485216 >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> From serguei.spitsyn at oracle.com Mon Apr 27 21:52:12 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2020 14:52:12 -0700 Subject: Fwd: RFR(S) 8231634: SA stack walking fails with "illegal bci" In-Reply-To: <62ffb3e0-242b-9210-662a-14a0f112e9a2@oracle.com> References: <8d9be633-2b65-a9b1-ddc1-ac89cf560474@oracle.com> <62ffb3e0-242b-9210-662a-14a0f112e9a2@oracle.com> Message-ID: <0eb5209a-ad4e-5f01-5eba-61bb48434925@oracle.com> An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Mon Apr 27 23:51:46 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 Apr 2020 16:51:46 -0700 Subject: RFR(T) : 8243928 : several svc tests can be run in driver mode Message-ID: <3B3C8318-74A9-4F93-81A5-642D9496FC50@oracle.com> http://cr.openjdk.java.net/~iignatyev//8243928/webrev.00 > 16 lines changed: 4 ins; 0 del; 12 mod; Hi all, could you please review the trivial patch which updates 15 svc tests to use a driver mode? from JBS: > the "main" classes of the tests listed below fork new JVMs and check their outputs, so there is no need to run them w/ external vm flags.<...> JBS: https://bugs.openjdk.java.net/browse/JDK-8243928 webrev: http://cr.openjdk.java.net/~iignatyev//8243928/webrev.00 Thanks, -- Igor From igor.ignatyev at oracle.com Mon Apr 27 23:58:28 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 Apr 2020 16:58:28 -0700 Subject: RFR(T) : 8243929 : use @requires in serviceability/attach/AttachWithStalePidFile.java test Message-ID: <2CD34808-4130-4AAC-8861-90FC999B2744@oracle.com> http://cr.openjdk.java.net/~iignatyev//8243929/webrev.00 > 7 lines changed: 1 ins; 6 del; 0 mod; Hi all, could you please review this trivial patch which updates AttachWithStalePidFile.java test to use @requires? from JBS: > serviceability/attach/AttachWithStalePidFile.java test can be run on windows and checks platform before executing any actual testing code. the modern faster and cleaner way to do it is using @requires. JBS: https://bugs.openjdk.java.net/browse/JDK-8243929 webrev: http://cr.openjdk.java.net/~iignatyev//8243929/webrev.00 Thanks, -- Igor From alexey.menkov at oracle.com Tue Apr 28 00:36:53 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 27 Apr 2020 17:36:53 -0700 Subject: RFR: JDK-8242522: Minor LingeredApp improvements In-Reply-To: References: <619494c6-4b0e-1c38-d9e4-2e57a511377a@oracle.com> <8341e8f7-8944-1dfd-6891-1846082fa5fe@oracle.com> Message-ID: <103ac919-26de-67fa-0872-c1b06c5df20d@oracle.com> updated webrev: http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev.2/ Moved getStdoutAsList to OutputBuffer. --alex On 04/24/2020 20:38, Chris Plummer wrote: > On 4/24/20 6:52 PM, Alex Menkov wrote: >> Hi Chris, >> >> On 04/24/2020 15:42, Chris Plummer wrote: >>> Hi Alex, >>> >>> Overall it looks good, although I'm not so sure I agree with removing >>> getAppOutput(). It's a generally useful utility API. Seems it is >>> better off in LingeredApp.java rather than in the one test that >>> currently uses it. >> >> To me the method just adds noise to the class. >> If you think it can be useful for some other tests, I'd move it to to >> OutputBuffer (make it default method which uses >> OutputBuffer.getStdout()): >> >> default public List getStdOutAsList() > I think that's a good idea. It looks like what tests are commonly doing > now is using String.split(): > > ??????????? String[] appLines?? = > app.getOutput().getStdout().split("\\R"); > > I'm not sure of the pros and cons of producing a String[] this way vs a > List using getStdOutAsList(). Maybe both have their uses. But > one thing for sure is the split() code is a lot more readable. One > reason I prefer getStdOutAsList() being placed in a library or utility > class is because TBH I find Streams code very hard to read, and > combining with chained Reader code doesn't help any, so I just assume it > be in a library that I'm less apt to look at rather than in the test > where I'm bound to find my eyes glazing over as I'm drawn in to figure > it out. > > Chris >> >> --alex >> >>> >>> thanks, >>> >>> Chris >>> >>> On 4/24/20 3:17 PM, Alex Menkov wrote: >>>> Hi all, >>>> >>>> Please review the fix for >>>> https://bugs.openjdk.java.net/browse/JDK-8242522 >>>> webrev: >>>> http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev/ >>>> >>>> The fix contains minor fixes/improvements for LingeredApp and tests >>>> which use it. See jira for details. >>>> >>>> Tested all tests which use LingeredApp. >>>> >>>> --alex >>> > > From alexey.menkov at oracle.com Tue Apr 28 01:23:16 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 27 Apr 2020 18:23:16 -0700 Subject: Fwd: RFR(S) 8231634: SA stack walking fails with "illegal bci" In-Reply-To: <0eb5209a-ad4e-5f01-5eba-61bb48434925@oracle.com> References: <8d9be633-2b65-a9b1-ddc1-ac89cf560474@oracle.com> <62ffb3e0-242b-9210-662a-14a0f112e9a2@oracle.com> <0eb5209a-ad4e-5f01-5eba-61bb48434925@oracle.com> Message-ID: <21d23148-9cc8-778b-994c-c5a3e5675fcc@oracle.com> Hi Chris, great analysis. LGTM++ --alex On 04/27/2020 14:52, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > The fix looks reasonable. > > Thanks, > Serguei > > > On 4/27/20 12:16, Chris Plummer wrote: >> Ping! Please help review if you can. There's also an RFR out for >> 8243500, which is related. >> >> thanks, >> >> Chris >> >> -------- Forwarded Message -------- >> Subject: RFR(S) 8231634: SA stack walking fails with "illegal bci" >> Date: Thu, 23 Apr 2020 14:35:49 -0700 >> From: Chris Plummer >> To: serviceability-dev >> >> >> >> Hello, >> >> Please help review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8231634 >> http://cr.openjdk.java.net/~cjplummer/8231634/webrev.00/index.html >> >> The fix is fairly simple: Don't use R13 as the BCP if it does not >> point into the methods actual bytecodes. Instead rely on the BCP value >> flushed to the frame. Details below are mostly there to help you >> understand the big picture of what is going on. >> >> First a bit a background on what the live_bcp field is in the >> X86Frame. BCP is "bytecode pointer". It points to the current bytecode >> being executed. I'm mostly just talking about interpreter frames here, >> but I think for compiled frames it points to the current native >> instruction being executed. For all but the current frame, frame->bcp >> reliably contains the BCP. For the current frame you normally need to >> look in a register for an up to date BCP. On x86_64 that's R13. When >> trying to find and create the current frame for a thread, eventually >> you end up in LinuxAMD64JavaThreadPDAccess.getCurrentFrameGuess(), >> which does: >> >> ????? // pass the value of R13 which contains the bcp for the top >> level frame >> ????? Address bcp = context.getRegisterAsAddress(AMD64ThreadContext.R13); >> ????? return new X86Frame(guesser.getSP(), guesser.getFP(), >> guesser.getPC(), null, bcp <-- live_bcp field); >> >> So in this case the X86Frame is constructed with R13 stored in the >> live_bcp field. For any frame other than the current frame, the >> live_bcp field will be NULL. >> >> And one other bit of clarification before moving on to the bug. You'll >> see BCX in code. For example, INTERPRETER_FRAME_BCX_OFFSET. BCX == >> BCP. I'm not sure why BCX was ever chosen. I was tempted to rename it >> to BCP, but it's been cloned to all the other SA CPU ports, so I think >> it's best to just leave it. >> >> Now on to the bug. Sometimes the interpreter uses R13 as a scratch >> register, so it does not always contain the BCP. This is why sometimes >> tests will see an "illegal bci" assert from SA. It's because r13 is >> currently not pointing to the BCP of the current frame, and thus can't >> be converted to a BCI. >> >> What this fix does take advantage of the fact that when r13 is used as >> a scratch register, it is first flushed to frame->bcp. So with this >> fix R13 is only used as the BCP if it points within the Method's >> bytecodes. If it does not, then SA will use the BCP flushed to >> frame->bcp. The reason we don't always used frame->bcp is because it >> is not kept up to date as the interpreter moves between bytecodes, but >> we know it is up to date if R13 is currently being used as a scratch >> register. So in other words, an invalid R13 implies that frame->bcp is >> up to date. >> >> And if you find yourself thinking "X86Frame.java supports is for both >> 32-bit and 64-bit x86, but R13 does not exists on 32-bit.", your >> right. A couple of years ago the concept of live_bcp was introduced to >> fix JDK-8214226 [1]. It only added support for fixing 64-bit and >> ignored 32-bit. So you'll never see live_bcp getting set for 32-bit, >> and thus JDK-8214226 is still broken on 32-bit, but it also means >> 32-bit is not impacted by the bug I'm fixing here. So the fix for >> JDK-8214226 is why you see R13 references in the X86Frame.java, but >> the code will still work for any platform that sets up live_bcd >> properly, even if it's not actually R13. >> >> ...and one more thing. 8214226 [1] actually introduced this "illegal >> bci" bug. However 8214226 [1] was only ever applied to LinuxAMD64. >> Never for BSD or Windows. This means two things: (1) the "illegal bci" >> bug never turned up on these platforms, and (2) 8214226 is still >> broken on these platform, meaning the bci returned by >> getInterpreterFrameBCI() is likely often stale, meaning stack traces >> will not show the proper line number for the current frame. It seems >> we don't have a test to catch this. I've filed 8243500 [2] to cover >> fixing 8214226 on BSD and Windows. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8214226 >> [2] https://bugs.openjdk.java.net/browse/JDK-8243500 >> >> thanks, >> >> Chris >> > From serguei.spitsyn at oracle.com Tue Apr 28 01:34:40 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2020 18:34:40 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> References: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Tue Apr 28 01:52:42 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 27 Apr 2020 18:52:42 -0700 Subject: RFR(M) 8243500: SA: Incorrect BCI and Line Number with jstack if the top frame is in the interpreter (BSD and Windows) In-Reply-To: <1566d163-631f-cb3c-3f75-0bcc230c38be@oracle.com> References: <02c3237c-8890-7c10-530b-5a6b52684126@oracle.com> <1566d163-631f-cb3c-3f75-0bcc230c38be@oracle.com> Message-ID: <9229141b-990b-1aea-4f49-a85c7ea931a8@oracle.com> Hi Chris, The fix looks good. --alex On 04/27/2020 12:17, Chris Plummer wrote: > Ping! Please help review if you can. > > thanks, > > Chris > > On 4/24/20 12:44 AM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8243500 >> http://cr.openjdk.java.net/~cjplummer/8243500/webrev.00/index.html >> >> A couple years ago JDK-8214226 fixed an issue on Linux-x64 with SA >> stack dumps not properly displaying the correct line number for the >> topmost frame if it was interpreted. The issue was that SA was always >> relying on frame->bcp when in fact the BCP is kept in R13, and only >> flushed to frame->bcp when needed as a scratch register. So this means >> that SA was in most cases grabbing a stale value from frame->bcp. >> >> The fix for JDK-8214226 was mostly made in X86Frame.java to support >> using the BCP register for the topmost frame instead using frame->bcp. >> This fix actually had a bug in it that was causing the "illegal bci" >> failures we've been seeing. There is already a separate webrev and RFR >> out for that: >> >> https://bugs.openjdk.java.net/browse/JDK-8231634 >> http://cr.openjdk.java.net/~cjplummer/8231634/webrev.00/index.html >> >> What this RFR addresses is the fact that part of the fix for >> JDK-8214226 was in LinuxAMD64JavaThreadPDAccess.java, but the same >> changes were never made to WindowsAMD64JavaThreadPDAccess.java or >> BsdAMD64JavaThreadPDAccess.java. This fix addresses those two ports. >> Here's the CR and changeset for reference: >> >> https://bugs.openjdk.java.net/browse/JDK-8214226 >> http://hg.openjdk.java.net/jdk/jdk/rev/9a73a4e4011f >> >> The changes for the fix are pretty trivial. The more complicated part >> is the test I added that will reproduce the issue 100% of the time on >> platforms where SA does not properly check the BCP register. For this >> reason I've used @requires to limit running this test on just those >> platforms I know have the support in place. The test has pretty good >> comments on how it works, so I won't go into details here. >> >> thanks, >> >> Chris > From alexey.menkov at oracle.com Tue Apr 28 02:36:21 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 27 Apr 2020 19:36:21 -0700 Subject: RFR(T) : 8243928 : several svc tests can be run in driver mode In-Reply-To: <3B3C8318-74A9-4F93-81A5-642D9496FC50@oracle.com> References: <3B3C8318-74A9-4F93-81A5-642D9496FC50@oracle.com> Message-ID: <84525844-0db7-49a7-eb00-0563d8c499cd@oracle.com> Hi Igor, LGTM --alex On 04/27/2020 16:51, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8243928/webrev.00 >> 16 lines changed: 4 ins; 0 del; 12 mod; > > > Hi all, > > could you please review the trivial patch which updates 15 svc tests to use a driver mode? > from JBS: >> the "main" classes of the tests listed below fork new JVMs and check their outputs, so there is no need to run them w/ external vm flags.<...> > > JBS: https://bugs.openjdk.java.net/browse/JDK-8243928 > webrev: http://cr.openjdk.java.net/~iignatyev//8243928/webrev.00 > > > Thanks, > -- Igor > > From igor.ignatyev at oracle.com Tue Apr 28 03:07:54 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 Apr 2020 20:07:54 -0700 Subject: RFR(T) : 8243928 : several svc tests can be run in driver mode In-Reply-To: <84525844-0db7-49a7-eb00-0563d8c499cd@oracle.com> References: <3B3C8318-74A9-4F93-81A5-642D9496FC50@oracle.com> <84525844-0db7-49a7-eb00-0563d8c499cd@oracle.com> Message-ID: Thanks Alex, pushed. -- Igor > On Apr 27, 2020, at 7:36 PM, Alex Menkov wrote: > > Hi Igor, > > LGTM > > --alex > > On 04/27/2020 16:51, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8243928/webrev.00 >>> 16 lines changed: 4 ins; 0 del; 12 mod; >> Hi all, >> could you please review the trivial patch which updates 15 svc tests to use a driver mode? >> from JBS: >>> the "main" classes of the tests listed below fork new JVMs and check their outputs, so there is no need to run them w/ external vm flags.<...> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8243928 >> webrev: http://cr.openjdk.java.net/~iignatyev//8243928/webrev.00 >> Thanks, >> -- Igor >> From serguei.spitsyn at oracle.com Tue Apr 28 03:52:42 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2020 20:52:42 -0700 Subject: trivial RFR(XS): 8243941: build issue introduced with the push of 8242237 Message-ID: <90768419-d63f-2f05-3d4f-aa45f6fe873f@oracle.com> An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Apr 28 03:53:33 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 Apr 2020 20:53:33 -0700 Subject: trivial RFR(XS): 8243941: build issue introduced with the push of 8242237 In-Reply-To: <90768419-d63f-2f05-3d4f-aa45f6fe873f@oracle.com> References: <90768419-d63f-2f05-3d4f-aa45f6fe873f@oracle.com> Message-ID: Hi Serguei, LGTM, -- Igor > On Apr 27, 2020, at 8:52 PM, serguei.spitsyn at oracle.com wrote: > > Please, review small patch to fix the build regression caused by fix of 8242237. > > Patch: > > diff --git a/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp b/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp > --- a/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp > +++ b/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp > @@ -242,7 +242,7 @@ > > /* Process a CLASS_LOAD or aClassPrepare event. */ > static void process_class_event(jvmtiEnv* jvmti, JNIEnv* jni, jclass klass, > - int* event_count_ptr, const char* event_name) { > + jint* event_count_ptr, const char* event_name) { > char* sig = NULL; > char* gsig = NULL; > jvmtiError err; > > > Summary: > Windows Compiler reports errors when a parameter is declared as 'int*' but jint* is actually used in the calls: > > ./open/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp(271): error C2664: 'void process_class_event(jvmtiEnv *,JNIEnv *,jclass,int *,const char *)': cannot convert argument 4 from 'jint *' to 'int *' > ./open/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp(271): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast > > > Testing: > A mach5 job build-tier1 submitted. > > Thanks, > serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 28 03:54:53 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2020 20:54:53 -0700 Subject: trivial RFR(XS): 8243941: build issue introduced with the push of 8242237 In-Reply-To: References: <90768419-d63f-2f05-3d4f-aa45f6fe873f@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Apr 28 03:55:52 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 Apr 2020 20:55:52 -0700 Subject: trivial RFR(XS): 8243941: build issue introduced with the push of 8242237 In-Reply-To: References: <90768419-d63f-2f05-3d4f-aa45f6fe873f@oracle.com> Message-ID: <0439B25C-731F-45AB-9CBB-712D2D4F923E@oracle.com> sure, and thank you, Serguei, for handling this so promptly! -- Igor > On Apr 27, 2020, at 8:54 PM, serguei.spitsyn at oracle.com wrote: > > Thanks, Igor! > Will push it after build-tier1 job is completed. > > Thanks, > Serguei > > On 4/27/20 20:53, Igor Ignatyev wrote: >> Hi Serguei, >> >> LGTM, >> >> -- Igor >> >>> On Apr 27, 2020, at 8:52 PM, serguei.spitsyn at oracle.com wrote: >>> >>> Please, review small patch to fix the build regression caused by fix of 8242237. >>> >>> Patch: >>> >>> diff --git a/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp b/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp >>> --- a/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp >>> +++ b/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp >>> @@ -242,7 +242,7 @@ >>> >>> /* Process a CLASS_LOAD or aClassPrepare event. */ >>> static void process_class_event(jvmtiEnv* jvmti, JNIEnv* jni, jclass klass, >>> - int* event_count_ptr, const char* event_name) { >>> + jint* event_count_ptr, const char* event_name) { >>> char* sig = NULL; >>> char* gsig = NULL; >>> jvmtiError err; >>> >>> >>> Summary: >>> Windows Compiler reports errors when a parameter is declared as 'int*' but jint* is actually used in the calls: >>> >>> ./open/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp(271): error C2664: 'void process_class_event(jvmtiEnv *,JNIEnv *,jclass,int *,const char *)': cannot convert argument 4 from 'jint *' to 'int *' >>> ./open/test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp(271): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast >>> >>> >>> Testing: >>> A mach5 job build-tier1 submitted. >>> >>> Thanks, >>> serguei >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 28 04:47:38 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2020 21:47:38 -0700 Subject: trivial RFR(XS): 8243941: build issue introduced with the push of 8242237 In-Reply-To: <0439B25C-731F-45AB-9CBB-712D2D4F923E@oracle.com> References: <90768419-d63f-2f05-3d4f-aa45f6fe873f@oracle.com> <0439B25C-731F-45AB-9CBB-712D2D4F923E@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Apr 28 05:02:22 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 Apr 2020 22:02:22 -0700 Subject: RFR(T) : 8243946 : serviceability/sa tests fail after JDK-8243928 Message-ID: <04E983CF-9D45-4806-9EFA-0DB6E95CE7ED@oracle.com> http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 > 2 lines changed: 0 ins; 0 del; 2 mod; Hi all, (so now it's my time to apology for inconvenience) could you please review this small follow-up fix/partial revert of 8243928[1]? serviceability/sa/TestCpoolForInvokeDynamic.java and TestDefaultMethods.java test use non-exported API so they can't be run in driver mode (b/c jtreg use vanilla JVM for driver code, meaning even exports from @modules tags are ignored) JBS: https://bugs.openjdk.java.net/browse/JDK-8243946 testing: test/hotspot/jtreg/serviceability (in progress) webrev: http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 [1] https://bugs.openjdk.java.net/browse/JDK-8243928 Thanks, -- Igor From mikael.vidstedt at oracle.com Tue Apr 28 05:10:05 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 27 Apr 2020 22:10:05 -0700 Subject: RFR(T) : 8243946 : serviceability/sa tests fail after JDK-8243928 In-Reply-To: <04E983CF-9D45-4806-9EFA-0DB6E95CE7ED@oracle.com> References: <04E983CF-9D45-4806-9EFA-0DB6E95CE7ED@oracle.com> Message-ID: <6F2FEEDB-56B6-4505-9009-65782A059C52@oracle.com> Looks good, thanks for the quick turnaround! Cheers, Mikael > On Apr 27, 2020, at 10:02 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >> 2 lines changed: 0 ins; 0 del; 2 mod; > > Hi all, > > (so now it's my time to apology for inconvenience) > > could you please review this small follow-up fix/partial revert of 8243928[1]? serviceability/sa/TestCpoolForInvokeDynamic.java and TestDefaultMethods.java test use non-exported API so they can't be run in driver mode (b/c jtreg use vanilla JVM for driver code, meaning even exports from @modules tags are ignored) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8243946 > testing: test/hotspot/jtreg/serviceability (in progress) > webrev: http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 > > [1] https://bugs.openjdk.java.net/browse/JDK-8243928 > > Thanks, > -- Igor From david.holmes at oracle.com Tue Apr 28 05:10:47 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Apr 2020 15:10:47 +1000 Subject: RFR(T) : 8243946 : serviceability/sa tests fail after JDK-8243928 In-Reply-To: <04E983CF-9D45-4806-9EFA-0DB6E95CE7ED@oracle.com> References: <04E983CF-9D45-4806-9EFA-0DB6E95CE7ED@oracle.com> Message-ID: <32eb80ee-f019-ff49-e3eb-b81baf30957f@oracle.com> Looks good and trivial. Thanks, David On 28/04/2020 3:02 pm, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >> 2 lines changed: 0 ins; 0 del; 2 mod; > > Hi all, > > (so now it's my time to apology for inconvenience) > > could you please review this small follow-up fix/partial revert of 8243928[1]? serviceability/sa/TestCpoolForInvokeDynamic.java and TestDefaultMethods.java test use non-exported API so they can't be run in driver mode (b/c jtreg use vanilla JVM for driver code, meaning even exports from @modules tags are ignored) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8243946 > testing: test/hotspot/jtreg/serviceability (in progress) > webrev: http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 > > [1] https://bugs.openjdk.java.net/browse/JDK-8243928 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Tue Apr 28 05:12:39 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 Apr 2020 22:12:39 -0700 Subject: RFR(T) : 8243946 : serviceability/sa tests fail after JDK-8243928 In-Reply-To: <6F2FEEDB-56B6-4505-9009-65782A059C52@oracle.com> References: <04E983CF-9D45-4806-9EFA-0DB6E95CE7ED@oracle.com> <6F2FEEDB-56B6-4505-9009-65782A059C52@oracle.com> Message-ID: Thanks Mikael, there is, thought, one more test failing after 8243928 -- serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java. the fix is pretty much the same revert part of 8243928: > diff -r 670000cbcf4f test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java > --- a/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java Mon Apr 27 20:06:22 2020 -0700 > +++ b/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java Mon Apr 27 22:11:31 2020 -0700 > @@ -30,7 +30,7 @@ > * @requires vm.cds > * @library /test/lib > * @compile CanGenerateAllClassHook.java > - * @run driver/native CanGenerateAllClassHook > + * @run main/native CanGenerateAllClassHook > */ > -- Igor > On Apr 27, 2020, at 10:10 PM, Mikael Vidstedt wrote: > > > Looks good, thanks for the quick turnaround! > > Cheers, > Mikael > >> On Apr 27, 2020, at 10:02 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >>> 2 lines changed: 0 ins; 0 del; 2 mod; >> >> Hi all, >> >> (so now it's my time to apology for inconvenience) >> >> could you please review this small follow-up fix/partial revert of 8243928[1]? serviceability/sa/TestCpoolForInvokeDynamic.java and TestDefaultMethods.java test use non-exported API so they can't be run in driver mode (b/c jtreg use vanilla JVM for driver code, meaning even exports from @modules tags are ignored) >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8243946 >> testing: test/hotspot/jtreg/serviceability (in progress) >> webrev: http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243928 >> >> Thanks, >> -- Igor > From serguei.spitsyn at oracle.com Tue Apr 28 05:14:48 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2020 22:14:48 -0700 Subject: RFR(T) : 8243946 : serviceability/sa tests fail after JDK-8243928 In-Reply-To: <6F2FEEDB-56B6-4505-9009-65782A059C52@oracle.com> References: <04E983CF-9D45-4806-9EFA-0DB6E95CE7ED@oracle.com> <6F2FEEDB-56B6-4505-9009-65782A059C52@oracle.com> Message-ID: <8deaaa1b-8a82-cd40-44e3-339074e56324@oracle.com> Hi Igor, Looks good but you have already pushed. :) Thanks, Serguei On 4/27/20 22:10, Mikael Vidstedt wrote: > Looks good, thanks for the quick turnaround! > > Cheers, > Mikael > >> On Apr 27, 2020, at 10:02 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >>> 2 lines changed: 0 ins; 0 del; 2 mod; >> Hi all, >> >> (so now it's my time to apology for inconvenience) >> >> could you please review this small follow-up fix/partial revert of 8243928[1]? serviceability/sa/TestCpoolForInvokeDynamic.java and TestDefaultMethods.java test use non-exported API so they can't be run in driver mode (b/c jtreg use vanilla JVM for driver code, meaning even exports from @modules tags are ignored) >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8243946 >> testing: test/hotspot/jtreg/serviceability (in progress) >> webrev: http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243928 >> >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Tue Apr 28 05:17:11 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 Apr 2020 22:17:11 -0700 Subject: RFR(T) : 8243946 : serviceability/sa tests fail after JDK-8243928 In-Reply-To: <8deaaa1b-8a82-cd40-44e3-339074e56324@oracle.com> References: <04E983CF-9D45-4806-9EFA-0DB6E95CE7ED@oracle.com> <6F2FEEDB-56B6-4505-9009-65782A059C52@oracle.com> <8deaaa1b-8a82-cd40-44e3-339074e56324@oracle.com> Message-ID: <36ADE18C-6449-4205-93C6-42C619809172@oracle.com> Hi Serguei, thanks for review, no I haven't yet as I found another problem w/ 8243928. -- Igor > On Apr 27, 2020, at 10:14 PM, serguei.spitsyn at oracle.com wrote: > > Hi Igor, > > Looks good but you have already pushed. :) > > Thanks, > Serguei > > > On 4/27/20 22:10, Mikael Vidstedt wrote: >> Looks good, thanks for the quick turnaround! >> >> Cheers, >> Mikael >> >>> On Apr 27, 2020, at 10:02 PM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >>>> 2 lines changed: 0 ins; 0 del; 2 mod; >>> Hi all, >>> >>> (so now it's my time to apology for inconvenience) >>> >>> could you please review this small follow-up fix/partial revert of 8243928[1]? serviceability/sa/TestCpoolForInvokeDynamic.java and TestDefaultMethods.java test use non-exported API so they can't be run in driver mode (b/c jtreg use vanilla JVM for driver code, meaning even exports from @modules tags are ignored) >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243946 >>> testing: test/hotspot/jtreg/serviceability (in progress) >>> webrev: http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8243928 >>> >>> Thanks, >>> -- Igor > From serguei.spitsyn at oracle.com Tue Apr 28 05:21:53 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Apr 2020 22:21:53 -0700 Subject: RFR(T) : 8243946 : serviceability/sa tests fail after JDK-8243928 In-Reply-To: References: <04E983CF-9D45-4806-9EFA-0DB6E95CE7ED@oracle.com> <6F2FEEDB-56B6-4505-9009-65782A059C52@oracle.com> Message-ID: <7b2ed6c9-aaf0-805c-1313-c41c99c4e820@oracle.com> This update looks good too. Thanks, Serguei On 4/27/20 22:12, Igor Ignatyev wrote: > Thanks Mikael, > > there is, thought, one more test failing after 8243928 -- serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java. the fix is pretty much the same revert part of 8243928: > >> diff -r 670000cbcf4f test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java >> --- a/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java Mon Apr 27 20:06:22 2020 -0700 >> +++ b/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java Mon Apr 27 22:11:31 2020 -0700 >> @@ -30,7 +30,7 @@ >> * @requires vm.cds >> * @library /test/lib >> * @compile CanGenerateAllClassHook.java >> - * @run driver/native CanGenerateAllClassHook >> + * @run main/native CanGenerateAllClassHook >> */ >> > > -- Igor > >> On Apr 27, 2020, at 10:10 PM, Mikael Vidstedt wrote: >> >> >> Looks good, thanks for the quick turnaround! >> >> Cheers, >> Mikael >> >>> On Apr 27, 2020, at 10:02 PM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >>>> 2 lines changed: 0 ins; 0 del; 2 mod; >>> Hi all, >>> >>> (so now it's my time to apology for inconvenience) >>> >>> could you please review this small follow-up fix/partial revert of 8243928[1]? serviceability/sa/TestCpoolForInvokeDynamic.java and TestDefaultMethods.java test use non-exported API so they can't be run in driver mode (b/c jtreg use vanilla JVM for driver code, meaning even exports from @modules tags are ignored) >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243946 >>> testing: test/hotspot/jtreg/serviceability (in progress) >>> webrev: http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8243928 >>> >>> Thanks, >>> -- Igor From igor.ignatyev at oracle.com Tue Apr 28 05:23:37 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 Apr 2020 22:23:37 -0700 Subject: RFR(T) : 8243946 : serviceability/sa tests fail after JDK-8243928 In-Reply-To: <7b2ed6c9-aaf0-805c-1313-c41c99c4e820@oracle.com> References: <04E983CF-9D45-4806-9EFA-0DB6E95CE7ED@oracle.com> <6F2FEEDB-56B6-4505-9009-65782A059C52@oracle.com> <7b2ed6c9-aaf0-805c-1313-c41c99c4e820@oracle.com> Message-ID: <8829629B-9CFE-4E5E-A18C-A9F1ACC987C1@oracle.com> thanks, i'll push it as soon as I get full test results (assuming there are no new failures). -- Igor > On Apr 27, 2020, at 10:21 PM, serguei.spitsyn at oracle.com wrote: > > This update looks good too. > > Thanks, > Serguei > > > On 4/27/20 22:12, Igor Ignatyev wrote: >> Thanks Mikael, >> >> there is, thought, one more test failing after 8243928 -- serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java. the fix is pretty much the same revert part of 8243928: >> >>> diff -r 670000cbcf4f test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java >>> --- a/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java Mon Apr 27 20:06:22 2020 -0700 >>> +++ b/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java Mon Apr 27 22:11:31 2020 -0700 >>> @@ -30,7 +30,7 @@ >>> * @requires vm.cds >>> * @library /test/lib >>> * @compile CanGenerateAllClassHook.java >>> - * @run driver/native CanGenerateAllClassHook >>> + * @run main/native CanGenerateAllClassHook >>> */ >>> >> >> -- Igor >> >>> On Apr 27, 2020, at 10:10 PM, Mikael Vidstedt wrote: >>> >>> >>> Looks good, thanks for the quick turnaround! >>> >>> Cheers, >>> Mikael >>> >>>> On Apr 27, 2020, at 10:02 PM, Igor Ignatyev wrote: >>>> >>>> http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >>>>> 2 lines changed: 0 ins; 0 del; 2 mod; >>>> Hi all, >>>> >>>> (so now it's my time to apology for inconvenience) >>>> >>>> could you please review this small follow-up fix/partial revert of 8243928[1]? serviceability/sa/TestCpoolForInvokeDynamic.java and TestDefaultMethods.java test use non-exported API so they can't be run in driver mode (b/c jtreg use vanilla JVM for driver code, meaning even exports from @modules tags are ignored) >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243946 >>>> testing: test/hotspot/jtreg/serviceability (in progress) >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8243946/webrev.00 >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8243928 >>>> >>>> Thanks, >>>> -- Igor > From linzang at tencent.com Tue Apr 28 05:54:58 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Tue, 28 Apr 2020 05:54:58 +0000 Subject: RFR(L): 8215624: add parallel heap inspection support for jmap histo(G1)(Internet mail) In-Reply-To: <4751f476-1e7a-490f-80c5-96b58eb25191@oracle.com> References: <94C0D11E-F395-4FE4-9ECE-5ECC84B3AE1B@tencent.com> <09702D94-F53C-413D-A156-B7390D689BC6@tencent.com> <4751f476-1e7a-490f-80c5-96b58eb25191@oracle.com> Message-ID: Hi Stefan, >> - Adding Atomic::load/store. >> - Removing the time measurement in the run_task. I renamed G1's function >> to run_task_timed. If we need this outside of G1, we can rethink the API >> at that point. >> - ZGC style cleanups Thanks for revising the patch, they are all good to me, and I have made a tiny change based on it: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_04/ http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_04-delta/ it reduce the scope of mutex in ParHeapInspectTask, and delete unnecessary comments. BRs, Lin ?On 2020/4/27, 4:34 PM, "Stefan Karlsson" wrote: Hi Lin, On 2020-04-26 05:10, linzang(??) wrote: > Hi Stefan and Paul? > I have made a new patch based on your comments and Stefan's Poc code: > Webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_03/ > Delta(based on Stefan's change:) : http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_03-delta/webrev_03-delta/ Thanks for providing a delta patch. It makes it much easier to look at, and more likely for reviewers to continue reviewing. I'm going to continue focusing on the GC parts, and leave the rest to others to review. > > And Here are main changed I made and want to discuss with you: > 1. changed"parallelThreadNum=" to "parallel=" for jmap -histo options. > 2. Add logic to test where parallelHeapInspection is fail, in heapInspection.cpp > This is because the parHeapInspectTask create thread local KlassInfoTable in it's work() method, and this may fail because of native OOM, in this case, the parallel should fail and serial heap inspection can be tried. > One more thing I want discuss with you is about the member "_success" of parHeapInspectTask, when native OOM happenes, it is set to false. And since this "set" operation can be conducted in multiple threads, should it be atomic ops? IMO, this is not necessary because "_success" can only be set to false, and there is no way to change it from back to true after the ParHeapInspectTask instance is created, so it is save to be non-atomic, do you agree with that? In these situations you should be using the Atomic::load/store primitives. We're moving toward a later C++ standard were data races are considered undefined behavior. > 3. make CollectedHeap::run_task() be an abstract virtual func, so that every subclass of collectedHeap should support it, so later implementation of new collectedHeap will not miss the "parallel" features. > The problem I want to discuss with you is about epsilonHeap and SerialHeap, as they may not need parallel heap iteration, so I only make task->work(0), in case the run_task() is invoked someway in future. Another way is to left run_task() unimplemented, which one do you think is better? I don't have a strong opinion about this. And also please help take a look at the zHeap, as there is a class zTask that wrap the abstractGangTask, and the collectedHeap::run_task() only accept AbstraceGangTask* as argument, so I made a delegate class to adapt it , please see src/hotspot/share/gc/z/zHeap.cpp. > > There maybe other better ways to sovle the above problems, welcome for any comments, Thanks! I've created a few cleanups and changes on top of your latest patch: https://cr.openjdk.java.net/~stefank/8215624/webrev.02.delta https://cr.openjdk.java.net/~stefank/8215624/webrev.02 - Adding Atomic::load/store. - Removing the time measurement in the run_task. I renamed G1's function to run_task_timed. If we need this outside of G1, we can rethink the API at that point. - ZGC style cleanups Thanks, StefanK > > BRs, > Lin > > On 2020/4/23, 11:08 AM, "linzang(??)" wrote: > > Thanks Paul! I agree with using "parallel", will make the update in next patch, Thanks for help update the CSR. > > BRs, > Lin > > On 2020/4/23, 4:42 AM, "Hohensee, Paul" wrote: > > For the interface, I'd use "parallel" instead of "parallelThreadNum". All the other options are lower case, and it's a lot easier to type "parallel". I took the liberty of updating the CSR. If you're ok with it, you might want to change variable names and such, plus of course JMap.usage. > > Thanks, > Paul > > On 4/22/20, 2:29 AM, "serviceability-dev on behalf of linzang(??)" wrote: > > Dear Stefan, > > Thanks a lot! I agree with you to decouple the heap inspection code with GC's. > I will start from your POC code, may discuss with you later. > > > BRs, > Lin > > On 2020/4/22, 5:14 PM, "Stefan Karlsson" wrote: > > Hi Lin, > > I took a look at this earlier and saw that the heap inspection code is > strongly coupled with the CollectedHeap and G1CollectedHeap. I'd prefer > if we'd abstract this away, so that the GCs only provide a "parallel > object iteration" interface, and the heap inspection code is kept elsewhere. > > I started experimenting with doing that, but other higher-priority (to > me) tasks have had to take precedence. > > I've uploaded my work-in-progress / proof-of-concept: > https://cr.openjdk.java.net/~stefank/8215624/webrev.01.delta/ > https://cr.openjdk.java.net/~stefank/8215624/webrev.01/ > > The current code doesn't handle the lifecycle (deletion) of the > ParallelObjectIterators. There's also code left unimplemented in around > CollectedHeap::run_task. However, I think this could work as a basis to > pull out the heap inspection code out of the GCs. > > Thanks, > StefanK > > On 2020-04-22 02:21, linzang(??) wrote: > > Dear all, > > May I ask you help to review? This RFR has been there for quite a while. > > Thanks! > > > > BRs, > > Lin > > > > > On 2020/3/16, 5:18 PM, "linzang(??)" wrote:> > > > >> Just update a new path, my preliminary measure show about 3.5x speedup of jmap histo on a nearly full 4GB G1 heap (8-core platform with parallel thread number set to 4). > >> webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_02/ > >> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 > >> CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 > >> BRs, > >> Lin > >> > On 2020/3/2, 9:56 PM, "linzang(??)" wrote: > >> > > >> > Dear all, > >> > Let me try to ease the reviewing work by some explanation :P > >> > The patch's target is to speed up jmap -histo for heap iteration, from my experience it is necessary for large heap investigation. E.g in bigData scenario I have tried to conduct jmap -histo against 180GB heap, it does take quite a while. > >> > And if my understanding is corrent, even the jmap -histo without "live" option does heap inspection with heap lock acquired. so it is very likely to block mutator thread in allocation-sensitive scenario. I would say the faster the heap inspection does, the shorter the mutator be blocked. This is parallel iteration for jmap is necessary. > >> > I think the parallel heap inspection should be applied to all kind of heap. However, consider the heap layout are different for GCs, much time is required to understand all kinds of the heap layout to make the whole change. IMO, It is not wise to have a huge patch for the whole solution at once, and it is even harder to review it. So I plan to implement it incrementally, the first patch (this one) is going to confirm the implemention detail of how jmap accept the new option, passes it to attachListener of the jvm process and then how to make the parallel inspection closure be generic enough to make it easy to extend to different heap layout. And also how to implement the heap inspection in specific gc's heap. This patch use G1's heap as the begining. > >> > This patch actually do several things: > >> > 1. Add an option "parallelThreadNum=" to jmap -histo, the default behavior is to set N to 0, means let's JVM decide how many threads to use for heap inspection. Set this option to 1 will disable parallel heap inspection. (more details in CSR: https://bugs.openjdk.java.net/browse/JDK-8239290) > >> > 2. Make a change in how Jmap passing arguments, changes in http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html, originally it pass options as separate arguments to attachListener, this patch change to that all options be compose to a single string. So the arg_count_max in attachListener.hpp do not need to be changed, and hence avoid the compatibility issue, as disscussed at https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027334.html > >> > 3. Add an abstract class ParHeapInspectTask in heapInspection.hpp / heapInspection.cpp, It's work(uint worker_id) method prepares the data structure (KlassInfoTable) need for every parallel worker thread, and then call do_object_iterate_parallel() which is heap specific implementation. I also added some machenism in KlassInfoTable to support parallel iteration, such as merge(). > >> > 4. In specific heap (G1 in this patch), create a subclass of ParHeapInspectTask, implement the do_object_iterate_parallel() for parallel heap inspection. For G1, it simply invoke g1CollectedHeap's object_iterate_parallel(). > >> > 5. Add related test. > >> > 6. it may be easy to extend this patch for other kinds of heap by creating subclass of ParHeapInspectTask and implement the do_object_iterate_parallel(). > >> > > >> > Hope these info could help on code review and initate the discussion :-) > >> > Thanks! > >> > > >> > BRs, > >> > Lin > >> > >On 2020/2/19, 9:40 AM, "linzang(??)" wrote:. > >> > > > >> > > Re-post this RFR with correct enhancement number to make it trackable. > >> > > please ignore the previous wrong post. sorry for troubles. > >> > > > >> > > webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/ > >> > > Hi bug: https://bugs.openjdk.java.net/browse/JDK-8215624 > >> > > CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 > >> > > -------------- > >> > > Lin > >> > > >Hi Lin, > > > > > > > >> > > >Could you, please, re-post your RFR with the right enhancement number in > >> > > >the message subject? > >> > > >It will be more trackable this way. > >> > > > > >> > > >Thanks, > >> > > >Serguei > >> > > > > >> > > > > >> > > >On 2/17/20 10:29 PM, linzang(??) wrote: > >> > > >> Dear David, > >> > > >> Thanks a lot! > >> > > >> I have updated the refined code to http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_01/. > >> > > >> IMHO the parallel heap inspection can be extended to all kinds of heap as long as the heap layout can support parallel iteration. > >> > > >> Maybe we can firstly use this webrev to discuss how to implement it, because I am not sure my current implementation is an appropriate way to communicate with collectedHeap, then we can extend the solution to other kinds of heap. > >> > > >> > >> > > >> Thanks, > >> > > >> -------------- > >> > > >> Lin > >> > > >>> Hi Lin, > >> > > >>> > >> > > >>> Adding in hotspot-gc-dev as they need to see how this interacts with GC > >> > > >>> worker threads, and whether it needs to be extended beyond G1. > >> > > >>> > >> > > >>> I happened to spot one nit when browsing: > >> > > >>> > >> > > >>> src/hotspot/share/gc/shared/collectedHeap.hpp > >> > > >>> > >> > > >>> + virtual bool run_par_heap_inspect_task(KlassInfoTable* cit, > >> > > >>> + BoolObjectClosure* filter, > >> > > >>> + size_t* missed_count, > >> > > >>> + size_t thread_num) { > >> > > >>> + return NULL; > >> > > >>> > >> > > >>> s/NULL/false/ > >> > > >>> > >> > > >>> Cheers, > >> > > >>> David > > > > > >>> > >> > > >>> On 18/02/2020 2:15 pm, linzang(??) wrote: > >> > > >>>> Dear All, > >> > > >>>> May I ask your help to review the follow changes: > >> > > >>>> webrev: > >> > > >>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_00/ > >> > > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 > >> > > >>>> related CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 > >> > > >>>> This patch enable parallel heap inspection of G1 for jmap histo. > >> > > >>>> my simple test shown it can speed up 2x of jmap -histo with > >> > > >>>> parallelThreadNum set to 2 for heap at ~500M on 4-core platform. > >> > > >>>> > >> > > >>>> ------------------------------------------------------------------------ > >> > > >>>> BRs, > >> > > >>>> Lin > >> > > >> > > >> > > > > > > > > > > > > > > > From igor.ignatyev at oracle.com Tue Apr 28 06:13:49 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 Apr 2020 23:13:49 -0700 Subject: RFR(T) : 8243954 : serviceability/logging/TestQuotedLogOutputs.java fails after 8243928 Message-ID: <94EF8435-5BDC-4488-9328-E6613737C539@oracle.com> Hi all, could you please review yet another follow up fix/revert for 8243928? patch: > diff -r 566418d35593 test/hotspot/jtreg/serviceability/logging/TestQuotedLogOutputs.java > --- a/test/hotspot/jtreg/serviceability/logging/TestQuotedLogOutputs.java Mon Apr 27 22:24:54 2020 -0700 > +++ b/test/hotspot/jtreg/serviceability/logging/TestQuotedLogOutputs.java Mon Apr 27 23:11:14 2020 -0700 > @@ -26,7 +26,8 @@ > * @summary Ensure proper parsing of quoted output names for -Xlog arguments. > * @modules java.base/jdk.internal.misc > * @library /test/lib > - * @run driver TestQuotedLogOutputs > + * @comment after JDK-8224505, this has to be run in othervm mode > + * @run main/othervm TestQuotedLogOutputs > */ > > import java.io.File; > JBS: https://bugs.openjdk.java.net/browse/JDK-8243954 Thanks, -- Igor From david.holmes at oracle.com Tue Apr 28 06:17:38 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Apr 2020 16:17:38 +1000 Subject: RFR(T) : 8243954 : serviceability/logging/TestQuotedLogOutputs.java fails after 8243928 In-Reply-To: <94EF8435-5BDC-4488-9328-E6613737C539@oracle.com> References: <94EF8435-5BDC-4488-9328-E6613737C539@oracle.com> Message-ID: <591da464-a535-7430-599a-295434998090@oracle.com> Looks good. Thanks, David On 28/04/2020 4:13 pm, Igor Ignatyev wrote: > > Hi all, > > could you please review yet another follow up fix/revert for 8243928? > > patch: >> diff -r 566418d35593 test/hotspot/jtreg/serviceability/logging/TestQuotedLogOutputs.java >> --- a/test/hotspot/jtreg/serviceability/logging/TestQuotedLogOutputs.java Mon Apr 27 22:24:54 2020 -0700 >> +++ b/test/hotspot/jtreg/serviceability/logging/TestQuotedLogOutputs.java Mon Apr 27 23:11:14 2020 -0700 >> @@ -26,7 +26,8 @@ >> * @summary Ensure proper parsing of quoted output names for -Xlog arguments. >> * @modules java.base/jdk.internal.misc >> * @library /test/lib >> - * @run driver TestQuotedLogOutputs >> + * @comment after JDK-8224505, this has to be run in othervm mode >> + * @run main/othervm TestQuotedLogOutputs >> */ >> >> import java.io.File; >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8243954 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Tue Apr 28 06:19:23 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 Apr 2020 23:19:23 -0700 Subject: RFR(T) : 8243954 : serviceability/logging/TestQuotedLogOutputs.java fails after 8243928 In-Reply-To: <591da464-a535-7430-599a-295434998090@oracle.com> References: <94EF8435-5BDC-4488-9328-E6613737C539@oracle.com> <591da464-a535-7430-599a-295434998090@oracle.com> Message-ID: <04248A91-CCCD-461D-9608-9841A4E3272A@oracle.com> thanks David, pushed. -- Igor > On Apr 27, 2020, at 11:17 PM, David Holmes wrote: > > Looks good. > > Thanks, > David > > On 28/04/2020 4:13 pm, Igor Ignatyev wrote: >> Hi all, >> could you please review yet another follow up fix/revert for 8243928? >> patch: >>> diff -r 566418d35593 test/hotspot/jtreg/serviceability/logging/TestQuotedLogOutputs.java >>> --- a/test/hotspot/jtreg/serviceability/logging/TestQuotedLogOutputs.java Mon Apr 27 22:24:54 2020 -0700 >>> +++ b/test/hotspot/jtreg/serviceability/logging/TestQuotedLogOutputs.java Mon Apr 27 23:11:14 2020 -0700 >>> @@ -26,7 +26,8 @@ >>> * @summary Ensure proper parsing of quoted output names for -Xlog arguments. >>> * @modules java.base/jdk.internal.misc >>> * @library /test/lib >>> - * @run driver TestQuotedLogOutputs >>> + * @comment after JDK-8224505, this has to be run in othervm mode >>> + * @run main/othervm TestQuotedLogOutputs >>> */ >>> import java.io.File; >>> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8243954 >> Thanks, >> -- Igor From david.holmes at oracle.com Tue Apr 28 09:38:37 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Apr 2020 19:38:37 +1000 Subject: URGENT (trivial) RFR: 8243989: test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java needs to use othervm Message-ID: https://bugs.openjdk.java.net/browse/JDK-8243989 diff -r 5dfc5e2f1bfc test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java --- a/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java +++ b/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java @@ -30,7 +30,7 @@ * @requires vm.cds * @library /test/lib * @compile CanGenerateAllClassHook.java - * @run main/native CanGenerateAllClassHook + * @run main/othervm/native CanGenerateAllClassHook */ Thanks, David From martin.doerr at sap.com Tue Apr 28 09:43:47 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 28 Apr 2020 09:43:47 +0000 Subject: URGENT (trivial) RFR: 8243989: test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java needs to use othervm In-Reply-To: References: Message-ID: Hi David, looks good and trivial. Best regards, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > David Holmes > Sent: Dienstag, 28. April 2020 11:39 > To: hotspot-dev developers ; > serviceability-dev > Subject: URGENT (trivial) RFR: 8243989: > test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGener > ateAllClassHook.java needs to use othervm > > https://bugs.openjdk.java.net/browse/JDK-8243989 > > diff -r 5dfc5e2f1bfc > test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGener > ateAllClassHook.java > --- > a/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGen > erateAllClassHook.java > +++ > b/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGen > erateAllClassHook.java > @@ -30,7 +30,7 @@ > * @requires vm.cds > * @library /test/lib > * @compile CanGenerateAllClassHook.java > - * @run main/native CanGenerateAllClassHook > + * @run main/othervm/native CanGenerateAllClassHook > */ > > > Thanks, > David From david.holmes at oracle.com Tue Apr 28 09:51:34 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Apr 2020 19:51:34 +1000 Subject: URGENT (trivial) RFR: 8243989: test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java needs to use othervm In-Reply-To: References: Message-ID: Thanks Martin! David On 28/04/2020 7:43 pm, Doerr, Martin wrote: > Hi David, > > looks good and trivial. > > Best regards, > Martin > > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> David Holmes >> Sent: Dienstag, 28. April 2020 11:39 >> To: hotspot-dev developers ; >> serviceability-dev >> Subject: URGENT (trivial) RFR: 8243989: >> test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGener >> ateAllClassHook.java needs to use othervm >> >> https://bugs.openjdk.java.net/browse/JDK-8243989 >> >> diff -r 5dfc5e2f1bfc >> test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGener >> ateAllClassHook.java >> --- >> a/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGen >> erateAllClassHook.java >> +++ >> b/test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGen >> erateAllClassHook.java >> @@ -30,7 +30,7 @@ >> * @requires vm.cds >> * @library /test/lib >> * @compile CanGenerateAllClassHook.java >> - * @run main/native CanGenerateAllClassHook >> + * @run main/othervm/native CanGenerateAllClassHook >> */ >> >> >> Thanks, >> David From leonid.mesnik at oracle.com Tue Apr 28 18:29:47 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 28 Apr 2020 11:29:47 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: References: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> Message-ID: Looks good. Leonid On 4/27/20 6:34 PM, serguei.spitsyn at oracle.com wrote: > Hi Leonid, > > Updated webrev version with the suggested refactoring is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.5/ > > > > > Please, see my comments below. > > On 4/24/20 13:20, Leonid Mesnik wrote: >> >> Hi >> >> I have several comments about coding and desing. These tests might be >> used as examples for new JDI tests based on this framework so I think >> it would be better to polish them. >> > > Yes, as we agreed it'd be nice to create good examples, a base for a > future test development in the JDI area. > I also wanted to polish these tests as much as possible, so thanks for > helping with it. > These are good suggestions from you below. > One problem is that these tests will differ in style from the rest of > the NSK JDI tests but it has to be okay. > > >> General comment: >> >> 1. You often check results (not null, exactly one result). >> >> It makes sense to use jdk.test.lib.Asserts for such verification. >> Just to reduce number of code and fail with standard exceptions. >> > > Good suggestion - fixed now. > >> 2. Wildcard imports like 'import com.sun.jdi.*;' are not recommended. >> > > Good suggestion - fixed. > The list of imports became big but I see no problem with that. > >> 3. I recommend to catch Throwable instead of Exception especially in >> non-main threads. Just to ensure that nothing is missed. >> > > God suggestion - fixed, at least, in places where it makes sense to do. > >> 4. nsk.share.Failure is subclass of RuntimeException so you don't >> need to add it to throws. Now sometimes it is added, sometimes not. >> It looks inconsistent. >> > > Good suggestion - fixed. > In fact, I did not like the use of Failure as it creates this > inconsistency, so I tried to get rid of it. > >> 5. There are lot of code duplication in debugger and debugge classes. >> Does it make a sense to merge it into base classes? >> > > I was thinking about this too but was reluctant to do so, as there are > just two tests. > But it has to be beneficial to move shared code to the JDI testing > framework. > I've just made some initial preparation by separating common parts > DebuggeeBase and DebuggerBase. > Also, it seems to be natural to move the HiddenClass and EventHandler > classes to their own files. > Then I've decided to combine both tests into one. > All refactoring still makes sense to have. > >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001.java.html >> >> 6. The getField can't return null, it verifies result. So check in >> line 191-193 is not needed. >> >> 190 Field field = getField(hcRefType, "hcField"); >> ?191 if (field == null) { >> 192 throw new Failure("TEST FAILED: cannot enable ModificationWhatchpointRequest: hcField not found"); >> 193 } > > Good catch - fixed. > >> >> 7. I would recommend to move all initialization from run in >> constructor and make most of variable 'final' it helps to ensure that >> they are initialized. >> 297 public int run(final String args[], final PrintStream out) { >> 298 ArgumentHandler argHandler = new ArgumentHandler(args); >> 299 >> 300 log = new Log(out, argHandler); >> 301 eventTimeout = argHandler.getWaitTime() * 60 * 1000; // milliseconds >> 302 launchDebuggee(argHandler); > > Right comment in general, but I did not go with a constructor and > final fields. > Instead, I've just reorganized this a little bit. > There is a little base to refactor to the constructor because the > field "log" needs to be static and timeout can be local. > > >> 8. Pair looks inconsistent. start saves handler as class field while >> join use as parameter. >> 305 startEventHandler(); >> 330 joinEventHandler(eventHandler); >> >> I think that something like >> EventHandler eventHandler = startEventHandler(); >> joinEventHandler(eventHandler); >> looks better and restrict usage of eventHandler. You also migt move >> methods startEventHandler into EventHandler itself. > > Good suggestion - fixed. Moved both methods to the EventHandler class. > >> >> 9. I suggest to make setHCRefType private and rename getHCRefType to >> something like receiveHCRefType. To make more clear that it is not a >> simple getter, but method which wait for event. >> 361 // Save hidden class ReferenceType when its ClassPrepare event is received. >> 362 synchronized void setHCRefType(ReferenceType type) { >> 363 hcRefType = type; >> 364 notifyAll(); >> 365 } >> 366 >> 367 // This method is used by the debugger main thread to wait and get >> 368 // the hidden class reference type from its ClassPrepare event. >> 369 // The readyCmdSync with the debuggeee is not enough because a >> 370 // ClassPrepare event sent over JDWP protocol has some delay. >> 371 // A wait/notify sync is to ensure the debugger gets non-null value. >> 372 synchronized ReferenceType getHCRefType() { >> 373 try { >> 374 while (hcRefType == null) { >> 375 wait(); >> 376 } >> 377 } catch (InterruptedException ie) { >> 378 throw new Failure("Unexpected InterruptedException in waiting for HC prepare: " + ie); >> 379 } >> 380 return hcRefType; >> 381 } > > Good suggestion - fixed. I've replaced getHCRefType with waitGetHCRefType. > Also, I've removed all uses of Failure and InterruptedException > catches and specified a couple of methods to throw InterruptedException. > >> >> 10. We don't run tests with -ea/esa so assertions usually disabled. >> Use Assertions from test lib instead. The comment 1) is >> recommendation only but 'assert' is just ignored. >> 436 assert name.indexOf("HiddenClass") > 0 && name.indexOf("/0x") > 0; > > Thanks - fixed. > >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001a.java.html >> >> >> 11. Check if jdk.test.lib.classloader.ClassLoadUtils. >> getClassPath(String className) works for you instead of >> 70 private static String getClassPath(Class klass) { >> >> 12. You could use try(log = new PrintStream("Debuggee.log")) {} here: >> 82 log = new PrintStream("Debuggee.log"); >> .. >> 86 try { >> .. >> ?90 } >> 91 log.close(); > > Good idea, but unfortunately it does not work as the field needs to be > static. > > >> 13. It is better to throw RuntimeException and don't add throws >> Exception in all methods. >> 95 private void syncWithDebugger(IOPipe pipe) throws Exception { > > Good suggestion - fixed. > > >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent/classUnloadEvent001a.java.html >> >> You could use single if for this. >> 122 if (command == null) { >> 123 throw new Exception("Failed: pipe.readln() returned null instead of COMMAND_QUIT"); >> 124 } else if (!command.equals(classUnloadEvent001.COMMAND_QUIT)) { >> 125 throw new Exception("Failed COMMAND_QUIT sync with debugger, got unknown command: " + command); >> 126 } > > I wanted a separate error message for (command == null) as it was > related to OOME on the debuggee side. > But it is not important anymore after the WT.fullGC() is used. > Fixed. > >> 14. Setting to null is not required to collect objects here. >> 151 hcObj = null; >> 152 hc = null; > > It is better to keep these to be sure the hidden class can be unloaded. > I had to create one mode hidden class to get a ClassUnload event. > There is a comment in the test debuggee explaining it. > > >> Probably I didn't catch all issues, but let discuss this list first. > > Okay. > > Thanks! > Serguei > >> Leonid >> >> On 4/23/20 9:01 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review a fix for the sub-task: >>> https://bugs.openjdk.java.net/browse/JDK-8241807 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/ >>> >>> >>> Summary; >>> ? This sub-task is to cover any hidden class related remaining >>> issues in the JDI and JDWP implementation. >>> ? In fact, no more issues were discovered with this extra test coverage. >>> ? So, this update includes only two new nsk jdi tests: >>> || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent >>> || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent >>> >>> ? These tests are to provide a test coverage? which was impossible >>> to provide with the jdb testing framework. >>> ? It includes ClassPrepare, Breakpoint and ModificationWatchpoint >>> events with class filters. >>> >>> Testing: >>> ? The mach5 job is in progress: >>> https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jdi-event-tests-20200424-0350-10464032 >>> >>> Thanks, >>> Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 28 18:47:16 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Apr 2020 11:47:16 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: References: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Apr 28 19:14:10 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 28 Apr 2020 12:14:10 -0700 Subject: Fwd: RFR(S) 8231634: SA stack walking fails with "illegal bci" In-Reply-To: <21d23148-9cc8-778b-994c-c5a3e5675fcc@oracle.com> References: <8d9be633-2b65-a9b1-ddc1-ac89cf560474@oracle.com> <62ffb3e0-242b-9210-662a-14a0f112e9a2@oracle.com> <0eb5209a-ad4e-5f01-5eba-61bb48434925@oracle.com> <21d23148-9cc8-778b-994c-c5a3e5675fcc@oracle.com> Message-ID: <099a20e0-6d63-bc04-c7db-faeb2b8f2067@oracle.com> Thanks Alex and Serguei! Chris On 4/27/20 6:23 PM, Alex Menkov wrote: > Hi Chris, > > great analysis. > LGTM++ > > --alex > > On 04/27/2020 14:52, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> The fix looks reasonable. >> >> Thanks, >> Serguei >> >> >> On 4/27/20 12:16, Chris Plummer wrote: >>> Ping! Please help review if you can. There's also an RFR out for >>> 8243500, which is related. >>> >>> thanks, >>> >>> Chris >>> >>> -------- Forwarded Message -------- >>> Subject:???? RFR(S) 8231634: SA stack walking fails with "illegal bci" >>> Date:???? Thu, 23 Apr 2020 14:35:49 -0700 >>> From:???? Chris Plummer >>> To:???? serviceability-dev >>> >>> >>> >>> Hello, >>> >>> Please help review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8231634 >>> http://cr.openjdk.java.net/~cjplummer/8231634/webrev.00/index.html >>> >>> The fix is fairly simple: Don't use R13 as the BCP if it does not >>> point into the methods actual bytecodes. Instead rely on the BCP >>> value flushed to the frame. Details below are mostly there to help >>> you understand the big picture of what is going on. >>> >>> First a bit a background on what the live_bcp field is in the >>> X86Frame. BCP is "bytecode pointer". It points to the current >>> bytecode being executed. I'm mostly just talking about interpreter >>> frames here, but I think for compiled frames it points to the >>> current native instruction being executed. For all but the current >>> frame, frame->bcp reliably contains the BCP. For the current frame >>> you normally need to look in a register for an up to date BCP. On >>> x86_64 that's R13. When trying to find and create the current frame >>> for a thread, eventually you end up in >>> LinuxAMD64JavaThreadPDAccess.getCurrentFrameGuess(), which does: >>> >>> ????? // pass the value of R13 which contains the bcp for the top >>> level frame >>> ????? Address bcp = >>> context.getRegisterAsAddress(AMD64ThreadContext.R13); >>> ????? return new X86Frame(guesser.getSP(), guesser.getFP(), >>> guesser.getPC(), null, bcp <-- live_bcp field); >>> >>> So in this case the X86Frame is constructed with R13 stored in the >>> live_bcp field. For any frame other than the current frame, the >>> live_bcp field will be NULL. >>> >>> And one other bit of clarification before moving on to the bug. >>> You'll see BCX in code. For example, INTERPRETER_FRAME_BCX_OFFSET. >>> BCX == BCP. I'm not sure why BCX was ever chosen. I was tempted to >>> rename it to BCP, but it's been cloned to all the other SA CPU >>> ports, so I think it's best to just leave it. >>> >>> Now on to the bug. Sometimes the interpreter uses R13 as a scratch >>> register, so it does not always contain the BCP. This is why >>> sometimes tests will see an "illegal bci" assert from SA. It's >>> because r13 is currently not pointing to the BCP of the current >>> frame, and thus can't be converted to a BCI. >>> >>> What this fix does take advantage of the fact that when r13 is used >>> as a scratch register, it is first flushed to frame->bcp. So with >>> this fix R13 is only used as the BCP if it points within the >>> Method's bytecodes. If it does not, then SA will use the BCP flushed >>> to frame->bcp. The reason we don't always used frame->bcp is because >>> it is not kept up to date as the interpreter moves between >>> bytecodes, but we know it is up to date if R13 is currently being >>> used as a scratch register. So in other words, an invalid R13 >>> implies that frame->bcp is up to date. >>> >>> And if you find yourself thinking "X86Frame.java supports is for >>> both 32-bit and 64-bit x86, but R13 does not exists on 32-bit.", >>> your right. A couple of years ago the concept of live_bcp was >>> introduced to fix JDK-8214226 [1]. It only added support for fixing >>> 64-bit and ignored 32-bit. So you'll never see live_bcp getting set >>> for 32-bit, and thus JDK-8214226 is still broken on 32-bit, but it >>> also means 32-bit is not impacted by the bug I'm fixing here. So the >>> fix for JDK-8214226 is why you see R13 references in the >>> X86Frame.java, but the code will still work for any platform that >>> sets up live_bcd properly, even if it's not actually R13. >>> >>> ...and one more thing. 8214226 [1] actually introduced this "illegal >>> bci" bug. However 8214226 [1] was only ever applied to LinuxAMD64. >>> Never for BSD or Windows. This means two things: (1) the "illegal >>> bci" bug never turned up on these platforms, and (2) 8214226 is >>> still broken on these platform, meaning the bci returned by >>> getInterpreterFrameBCI() is likely often stale, meaning stack traces >>> will not show the proper line number for the current frame. It seems >>> we don't have a test to catch this. I've filed 8243500 [2] to cover >>> fixing 8214226 on BSD and Windows. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8214226 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8243500 >>> >>> thanks, >>> >>> Chris >>> >> From chris.plummer at oracle.com Tue Apr 28 19:16:24 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 28 Apr 2020 12:16:24 -0700 Subject: RFR(M) 8243500: SA: Incorrect BCI and Line Number with jstack if the top frame is in the interpreter (BSD and Windows) In-Reply-To: <9229141b-990b-1aea-4f49-a85c7ea931a8@oracle.com> References: <02c3237c-8890-7c10-530b-5a6b52684126@oracle.com> <1566d163-631f-cb3c-3f75-0bcc230c38be@oracle.com> <9229141b-990b-1aea-4f49-a85c7ea931a8@oracle.com> Message-ID: Thanks Alex! Can I get one more review please? Chris On 4/27/20 6:52 PM, Alex Menkov wrote: > Hi Chris, > > The fix looks good. > > --alex > > On 04/27/2020 12:17, Chris Plummer wrote: >> Ping! Please help review if you can. >> >> thanks, >> >> Chris >> >> On 4/24/20 12:44 AM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8243500 >>> http://cr.openjdk.java.net/~cjplummer/8243500/webrev.00/index.html >>> >>> A couple years ago JDK-8214226 fixed an issue on Linux-x64 with SA >>> stack dumps not properly displaying the correct line number for the >>> topmost frame if it was interpreted. The issue was that SA was >>> always relying on frame->bcp when in fact the BCP is kept in R13, >>> and only flushed to frame->bcp when needed as a scratch register. So >>> this means that SA was in most cases grabbing a stale value from >>> frame->bcp. >>> >>> The fix for JDK-8214226 was mostly made in X86Frame.java to support >>> using the BCP register for the topmost frame instead using >>> frame->bcp. This fix actually had a bug in it that was causing the >>> "illegal bci" failures we've been seeing. There is already a >>> separate webrev and RFR out for that: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8231634 >>> http://cr.openjdk.java.net/~cjplummer/8231634/webrev.00/index.html >>> >>> What this RFR addresses is the fact that part of the fix for >>> JDK-8214226 was in LinuxAMD64JavaThreadPDAccess.java, but the same >>> changes were never made to WindowsAMD64JavaThreadPDAccess.java or >>> BsdAMD64JavaThreadPDAccess.java. This fix addresses those two ports. >>> Here's the CR and changeset for reference: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214226 >>> http://hg.openjdk.java.net/jdk/jdk/rev/9a73a4e4011f >>> >>> The changes for the fix are pretty trivial. The more complicated >>> part is the test I added that will reproduce the issue 100% of the >>> time on platforms where SA does not properly check the BCP register. >>> For this reason I've used @requires to limit running this test on >>> just those platforms I know have the support in place. The test has >>> pretty good comments on how it works, so I won't go into details here. >>> >>> thanks, >>> >>> Chris >> From serguei.spitsyn at oracle.com Tue Apr 28 20:02:26 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Apr 2020 13:02:26 -0700 Subject: RFR(M) 8243500: SA: Incorrect BCI and Line Number with jstack if the top frame is in the interpreter (BSD and Windows) In-Reply-To: References: <02c3237c-8890-7c10-530b-5a6b52684126@oracle.com> <1566d163-631f-cb3c-3f75-0bcc230c38be@oracle.com> <9229141b-990b-1aea-4f49-a85c7ea931a8@oracle.com> Message-ID: <99c16f51-2c88-318d-c8ae-b2a38c088d05@oracle.com> Hi Chris, LGTM++ The test is interesting. Thanks, Serguei On 4/28/20 12:16, Chris Plummer wrote: > Thanks Alex! > > Can I get one more review please? > > Chris > > On 4/27/20 6:52 PM, Alex Menkov wrote: >> Hi Chris, >> >> The fix looks good. >> >> --alex >> >> On 04/27/2020 12:17, Chris Plummer wrote: >>> Ping! Please help review if you can. >>> >>> thanks, >>> >>> Chris >>> >>> On 4/24/20 12:44 AM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8243500 >>>> http://cr.openjdk.java.net/~cjplummer/8243500/webrev.00/index.html >>>> >>>> A couple years ago JDK-8214226 fixed an issue on Linux-x64 with SA >>>> stack dumps not properly displaying the correct line number for the >>>> topmost frame if it was interpreted. The issue was that SA was >>>> always relying on frame->bcp when in fact the BCP is kept in R13, >>>> and only flushed to frame->bcp when needed as a scratch register. >>>> So this means that SA was in most cases grabbing a stale value from >>>> frame->bcp. >>>> >>>> The fix for JDK-8214226 was mostly made in X86Frame.java to support >>>> using the BCP register for the topmost frame instead using >>>> frame->bcp. This fix actually had a bug in it that was causing the >>>> "illegal bci" failures we've been seeing. There is already a >>>> separate webrev and RFR out for that: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8231634 >>>> http://cr.openjdk.java.net/~cjplummer/8231634/webrev.00/index.html >>>> >>>> What this RFR addresses is the fact that part of the fix for >>>> JDK-8214226 was in LinuxAMD64JavaThreadPDAccess.java, but the same >>>> changes were never made to WindowsAMD64JavaThreadPDAccess.java or >>>> BsdAMD64JavaThreadPDAccess.java. This fix addresses those two >>>> ports. Here's the CR and changeset for reference: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8214226 >>>> http://hg.openjdk.java.net/jdk/jdk/rev/9a73a4e4011f >>>> >>>> The changes for the fix are pretty trivial. The more complicated >>>> part is the test I added that will reproduce the issue 100% of the >>>> time on platforms where SA does not properly check the BCP >>>> register. For this reason I've used @requires to limit running this >>>> test on just those platforms I know have the support in place. The >>>> test has pretty good comments on how it works, so I won't go into >>>> details here. >>>> >>>> thanks, >>>> >>>> Chris >>> > From chris.plummer at oracle.com Tue Apr 28 20:31:38 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 28 Apr 2020 13:31:38 -0700 Subject: RFR(M) 8243500: SA: Incorrect BCI and Line Number with jstack if the top frame is in the interpreter (BSD and Windows) In-Reply-To: <99c16f51-2c88-318d-c8ae-b2a38c088d05@oracle.com> References: <02c3237c-8890-7c10-530b-5a6b52684126@oracle.com> <1566d163-631f-cb3c-3f75-0bcc230c38be@oracle.com> <9229141b-990b-1aea-4f49-a85c7ea931a8@oracle.com> <99c16f51-2c88-318d-c8ae-b2a38c088d05@oracle.com> Message-ID: Yeah, it took a while for me to come up with a reasonable test. It possibly could use some tuning. I first required it match 5 out of 5 lines, and do so in 30 seconds. Then I realized that a fixed time wasn't a good idea, nor matching every line. It failed frequently, mostly on slower machines but sometimes even on fast machines due to bad luck. So I figured out how to get the target to terminate when the main test was done so a timer wasn't needed, and also relaxed the requirement for matching every line so the test wouldn't need to run as long, eventually settling on 5 out of 10 lines instead of 5 out of 5. A port without the 8231634 fix will at most match 2 lines (start and end of loop) although I think I only ever saw it match the line at the start of the loop. thanks, Chris On 4/28/20 1:02 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > LGTM++ > The test is interesting. > > Thanks, > Serguei > > > > On 4/28/20 12:16, Chris Plummer wrote: >> Thanks Alex! >> >> Can I get one more review please? >> >> Chris >> >> On 4/27/20 6:52 PM, Alex Menkov wrote: >>> Hi Chris, >>> >>> The fix looks good. >>> >>> --alex >>> >>> On 04/27/2020 12:17, Chris Plummer wrote: >>>> Ping! Please help review if you can. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 4/24/20 12:44 AM, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8243500 >>>>> http://cr.openjdk.java.net/~cjplummer/8243500/webrev.00/index.html >>>>> >>>>> A couple years ago JDK-8214226 fixed an issue on Linux-x64 with SA >>>>> stack dumps not properly displaying the correct line number for >>>>> the topmost frame if it was interpreted. The issue was that SA was >>>>> always relying on frame->bcp when in fact the BCP is kept in R13, >>>>> and only flushed to frame->bcp when needed as a scratch register. >>>>> So this means that SA was in most cases grabbing a stale value >>>>> from frame->bcp. >>>>> >>>>> The fix for JDK-8214226 was mostly made in X86Frame.java to >>>>> support using the BCP register for the topmost frame instead using >>>>> frame->bcp. This fix actually had a bug in it that was causing the >>>>> "illegal bci" failures we've been seeing. There is already a >>>>> separate webrev and RFR out for that: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8231634 >>>>> http://cr.openjdk.java.net/~cjplummer/8231634/webrev.00/index.html >>>>> >>>>> What this RFR addresses is the fact that part of the fix for >>>>> JDK-8214226 was in LinuxAMD64JavaThreadPDAccess.java, but the same >>>>> changes were never made to WindowsAMD64JavaThreadPDAccess.java or >>>>> BsdAMD64JavaThreadPDAccess.java. This fix addresses those two >>>>> ports. Here's the CR and changeset for reference: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8214226 >>>>> http://hg.openjdk.java.net/jdk/jdk/rev/9a73a4e4011f >>>>> >>>>> The changes for the fix are pretty trivial. The more complicated >>>>> part is the test I added that will reproduce the issue 100% of the >>>>> time on platforms where SA does not properly check the BCP >>>>> register. For this reason I've used @requires to limit running >>>>> this test on just those platforms I know have the support in >>>>> place. The test has pretty good comments on how it works, so I >>>>> won't go into details here. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>> >> > From chris.plummer at oracle.com Tue Apr 28 20:57:22 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 28 Apr 2020 13:57:22 -0700 Subject: RFR(T) JDK-8214797: TestJmapCoreMetaspace.java timed out Message-ID: <298195da-970f-f069-5020-fb2f3cc337be@oracle.com> Hello, Please review the following trivial change: diff --git a/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java b/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java --- a/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java +++ b/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -26,5 +26,5 @@ ? * @summary Test verifies that jhsdb jmap could generate heap dump from core when metspace is full ? * @requires vm.hasSA ? * @library /test/lib - * @run driver/timeout=240 TestJmapCore run metaspace + * @run driver/timeout=480 TestJmapCore run metaspace ? */ Sometimes on our macs a core dump takes much longer than usual. The usual time is not much different than our other hosts, typically taking 3-5 minutes. However some times it takes much longer. We've seen them take up to 27 minutes. Once it approaches 18 minutes, that's when you see test timeouts. Doubling the timeout gives us 32 minutes, which would at least have prevented any of the timeouts we've seen so far. BTW, limiting the timeout does not seem to limit how long the test takes when one of these core dumps takes a long time. The test will not complete (and then timeout) until the core dump is done. So this change is not impacting how much time we spend on the test if we encounter an even longer core dump that results in a timeout. thanks, Chris From alexey.menkov at oracle.com Wed Apr 29 00:35:46 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 28 Apr 2020 17:35:46 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: References: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> Message-ID: Hi Serguei, Looks good in general. couple minor notes: DebuggerBase.java - vm, debuggee, pipe and erManager fields and getDebuggee(), vm() methods don't need to be static; - replace all "imultiple" with "multiple". --alex On 04/27/2020 18:34, serguei.spitsyn at oracle.com wrote: > Hi Leonid, > > Updated webrev version with the suggested refactoring is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.5/ > > > > > Please, see my comments below. > > On 4/24/20 13:20, Leonid Mesnik wrote: >> >> Hi >> >> I have several comments about coding and desing. These tests might be >> used as examples for new JDI tests based on this framework so I think >> it would be better to polish them. >> > > Yes, as we agreed it'd be nice to create good examples, a base for a > future test development in the JDI area. > I also wanted to polish these tests as much as possible, so thanks for > helping with it. > These are good suggestions from you below. > One problem is that these tests will differ in style from the rest of > the NSK JDI tests but it has to be okay. > > >> General comment: >> >> 1. You often check results (not null, exactly one result). >> >> It makes sense to use jdk.test.lib.Asserts for such verification. Just >> to reduce number of code and fail with standard exceptions. >> > > Good suggestion - fixed now. > >> 2. Wildcard imports like 'import com.sun.jdi.*;' are not recommended. >> > > Good suggestion - fixed. > The list of imports became big but I see no problem with that. > >> 3. I recommend to catch Throwable instead of Exception especially in >> non-main threads. Just to ensure that nothing is missed. >> > > God suggestion - fixed, at least, in places where it makes sense to do. > >> 4. nsk.share.Failure is subclass of RuntimeException so you don't need >> to add it to throws. Now sometimes it is added, sometimes not. It >> looks inconsistent. >> > > Good suggestion - fixed. > In fact, I did not like the use of Failure as it creates this > inconsistency, so I tried to get rid of it. > >> 5. There are lot of code duplication in debugger and debugge classes. >> Does it make a sense to merge it into base classes? >> > > I was thinking about this too but was reluctant to do so, as there are > just two tests. > But it has to be beneficial to move shared code to the JDI testing > framework. > I've just made some initial preparation by separating common parts > DebuggeeBase and DebuggerBase. > Also, it seems to be natural to move the HiddenClass and EventHandler > classes to their own files. > Then I've decided to combine both tests into one. > All refactoring still makes sense to have. > >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001.java.html >> >> 6. The getField can't return null, it verifies result. So check in >> line 191-193 is not needed. >> >> 190 Field field = getField(hcRefType, "hcField"); >> ?191 if (field == null) { >> 192 throw new Failure("TEST FAILED: cannot enable ModificationWhatchpointRequest: hcField not found"); >> 193 } > > Good catch - fixed. > >> >> 7. I would recommend to move all initialization from run in >> constructor and make most of variable 'final' it helps to ensure that >> they are initialized. >> 297 public int run(final String args[], final PrintStream out) { >> 298 ArgumentHandler argHandler = new ArgumentHandler(args); >> 299 >> 300 log = new Log(out, argHandler); >> 301 eventTimeout = argHandler.getWaitTime() * 60 * 1000; // milliseconds >> 302 launchDebuggee(argHandler); > > Right comment in general, but I did not go with a constructor and final > fields. > Instead, I've just reorganized this a little bit. > There is a little base to refactor to the constructor because the field > "log" needs to be static and timeout can be local. > > >> 8. Pair looks inconsistent. start saves handler as class field while >> join use as parameter. >> 305 startEventHandler(); >> 330 joinEventHandler(eventHandler); >> >> I think that something like >> EventHandler eventHandler = startEventHandler(); >> joinEventHandler(eventHandler); >> looks better and restrict usage of eventHandler. You also migt move >> methods startEventHandler into EventHandler itself. > > Good suggestion - fixed. Moved both methods to the EventHandler class. > >> >> 9. I suggest to make setHCRefType private and rename getHCRefType to >> something like receiveHCRefType. To make more clear that it is not a >> simple getter, but method which wait for event. >> 361 // Save hidden class ReferenceType when its ClassPrepare event is received. >> 362 synchronized void setHCRefType(ReferenceType type) { >> 363 hcRefType = type; >> 364 notifyAll(); >> 365 } >> 366 >> 367 // This method is used by the debugger main thread to wait and get >> 368 // the hidden class reference type from its ClassPrepare event. >> 369 // The readyCmdSync with the debuggeee is not enough because a >> 370 // ClassPrepare event sent over JDWP protocol has some delay. >> 371 // A wait/notify sync is to ensure the debugger gets non-null value. >> 372 synchronized ReferenceType getHCRefType() { >> 373 try { >> 374 while (hcRefType == null) { >> 375 wait(); >> 376 } >> 377 } catch (InterruptedException ie) { >> 378 throw new Failure("Unexpected InterruptedException in waiting for HC prepare: " + ie); >> 379 } >> 380 return hcRefType; >> 381 } > > Good suggestion - fixed. I've replaced getHCRefType with waitGetHCRefType. > Also, I've removed all uses of Failure and InterruptedException catches > and specified a couple of methods to throw InterruptedException. > >> >> 10. We don't run tests with -ea/esa so assertions usually disabled. >> Use Assertions from test lib instead. The comment 1) is recommendation >> only but 'assert' is just ignored. >> 436 assert name.indexOf("HiddenClass") > 0 && name.indexOf("/0x") > 0; > > Thanks - fixed. > >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001a.java.html >> >> >> 11. Check if jdk.test.lib.classloader.ClassLoadUtils. >> getClassPath(String className) works for you instead of >> 70 private static String getClassPath(Class klass) { >> >> 12. You could use try(log = new PrintStream("Debuggee.log")) {} here: >> 82 log = new PrintStream("Debuggee.log"); >> .. >> 86 try { >> .. >> ?90 } >> 91 log.close(); > > Good idea, but unfortunately it does not work as the field needs to be > static. > > >> 13. It is better to throw RuntimeException and don't add throws >> Exception in all methods. >> 95 private void syncWithDebugger(IOPipe pipe) throws Exception { > > Good suggestion - fixed. > > >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent/classUnloadEvent001a.java.html >> >> You could use single if for this. >> 122 if (command == null) { >> 123 throw new Exception("Failed: pipe.readln() returned null instead of COMMAND_QUIT"); >> 124 } else if (!command.equals(classUnloadEvent001.COMMAND_QUIT)) { >> 125 throw new Exception("Failed COMMAND_QUIT sync with debugger, got unknown command: " + command); >> 126 } > > I wanted a separate error message for (command == null) as it was > related to OOME on the debuggee side. > But it is not important anymore after the WT.fullGC() is used. > Fixed. > >> 14. Setting to null is not required to collect objects here. >> 151 hcObj = null; >> 152 hc = null; > > It is better to keep these to be sure the hidden class can be unloaded. > I had to create one mode hidden class to get a ClassUnload event. > There is a comment in the test debuggee explaining it. > > >> Probably I didn't catch all issues, but let discuss this list first. > > Okay. > > Thanks! > Serguei > >> Leonid >> >> On 4/23/20 9:01 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review a fix for the sub-task: >>> https://bugs.openjdk.java.net/browse/JDK-8241807 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/ >>> >>> >>> Summary; >>> ? This sub-task is to cover any hidden class related remaining issues >>> in the JDI and JDWP implementation. >>> ? In fact, no more issues were discovered with this extra test coverage. >>> ? So, this update includes only two new nsk jdi tests: >>> || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent >>> || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent >>> >>> ? These tests are to provide a test coverage? which was impossible to >>> provide with the jdb testing framework. >>> ? It includes ClassPrepare, Breakpoint and ModificationWatchpoint >>> events with class filters. >>> >>> Testing: >>> ? The mach5 job is in progress: >>> https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jdi-event-tests-20200424-0350-10464032 >>> >>> Thanks, >>> Serguei > From serguei.spitsyn at oracle.com Wed Apr 29 01:03:33 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Apr 2020 18:03:33 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: References: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> Message-ID: Hi Alex, Thank you a lot for reviewing this. On 4/28/20 17:35, Alex Menkov wrote: > Hi Serguei, > > Looks good in general. > couple minor notes: > > DebuggerBase.java > > - vm, debuggee, pipe and erManager fields and getDebuggee(), vm() > methods don't need to be static; Thank you for the suggestion. The erManager and pipe are not static. It feels like you need to refresh the webrev pages as I've updated the webrev in place a couple of times while waited for review. The vm() method is used in the EventHandler class which does not have a reference to the DebuggerBase object. It is why the vm() needs to be static. The same is true for 4 other methods: getReferenceType(), findField(), findMethod() and invokeStaticMethod(). I was also thinking on how to get rid of this staic-ness and decided to leave it alone. The getDebuggee() method is not used yet. I've removed it. It is not a problem to add it back in case it is needed. > > - replace all "imultiple" with "multiple". Nice catch - fixed. Thanks, Serguei > > --alex > > > On 04/27/2020 18:34, serguei.spitsyn at oracle.com wrote: >> Hi Leonid, >> >> Updated webrev version with the suggested refactoring is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.5/ >> >> >> >> >> >> >> Please, see my comments below. >> >> On 4/24/20 13:20, Leonid Mesnik wrote: >>> >>> Hi >>> >>> I have several comments about coding and desing. These tests might >>> be used as examples for new JDI tests based on this framework so I >>> think it would be better to polish them. >>> >> >> Yes, as we agreed it'd be nice to create good examples, a base for a >> future test development in the JDI area. >> I also wanted to polish these tests as much as possible, so thanks >> for helping with it. >> These are good suggestions from you below. >> One problem is that these tests will differ in style from the rest of >> the NSK JDI tests but it has to be okay. >> >> >>> General comment: >>> >>> 1. You often check results (not null, exactly one result). >>> >>> It makes sense to use jdk.test.lib.Asserts for such verification. >>> Just to reduce number of code and fail with standard exceptions. >>> >> >> Good suggestion - fixed now. >> >>> 2. Wildcard imports like 'import com.sun.jdi.*;' are not recommended. >>> >> >> Good suggestion - fixed. >> The list of imports became big but I see no problem with that. >> >>> 3. I recommend to catch Throwable instead of Exception especially in >>> non-main threads. Just to ensure that nothing is missed. >>> >> >> God suggestion - fixed, at least, in places where it makes sense to do. >> >>> 4. nsk.share.Failure is subclass of RuntimeException so you don't >>> need to add it to throws. Now sometimes it is added, sometimes not. >>> It looks inconsistent. >>> >> >> Good suggestion - fixed. >> In fact, I did not like the use of Failure as it creates this >> inconsistency, so I tried to get rid of it. >> >>> 5. There are lot of code duplication in debugger and debugge >>> classes. Does it make a sense to merge it into base classes? >>> >> >> I was thinking about this too but was reluctant to do so, as there >> are just two tests. >> But it has to be beneficial to move shared code to the JDI testing >> framework. >> I've just made some initial preparation by separating common parts >> DebuggeeBase and DebuggerBase. >> Also, it seems to be natural to move the HiddenClass and EventHandler >> classes to their own files. >> Then I've decided to combine both tests into one. >> All refactoring still makes sense to have. >> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001.java.html >>> >>> >>> 6. The getField can't return null, it verifies result. So check in >>> line 191-193 is not needed. >>> >>> ? 190???????? Field field = getField(hcRefType, "hcField"); >>> ??191???????? if (field == null) { >>> ? 192???????????? throw new Failure("TEST FAILED: cannot enable >>> ModificationWhatchpointRequest: hcField not found"); >>> ? 193???????? } >> >> Good catch - fixed. >> >>> >>> 7. I would recommend to move all initialization from run in >>> constructor and make most of variable 'final' it helps to ensure >>> that they are initialized. >>> ? 297???? public int run(final String args[], final PrintStream out) { >>> ? 298???????? ArgumentHandler argHandler = new ArgumentHandler(args); >>> ? 299 >>> ? 300???????? log = new Log(out, argHandler); >>> ? 301???????? eventTimeout = argHandler.getWaitTime() * 60 * 1000; >>> // milliseconds >>> ? 302???????? launchDebuggee(argHandler); >> >> Right comment in general, but I did not go with a constructor and >> final fields. >> Instead, I've just reorganized this a little bit. >> There is a little base to refactor to the constructor because the >> field "log" needs to be static and timeout can be local. >> >> >>> 8. Pair looks inconsistent. start saves handler as class field while >>> join use as parameter. >>> 305???????????? startEventHandler(); >>> 330???????????? joinEventHandler(eventHandler); >>> >>> I think that something like >>> EventHandler eventHandler = startEventHandler(); >>> joinEventHandler(eventHandler); >>> looks better and restrict usage of eventHandler. You also migt move >>> methods startEventHandler into EventHandler itself. >> >> Good suggestion - fixed. Moved both methods to the EventHandler class. >> >>> >>> 9. I suggest to make setHCRefType private and rename getHCRefType to >>> something like receiveHCRefType. To make more clear that it is not a >>> simple getter, but method which wait for event. >>> ? 361???????? // Save hidden class ReferenceType when its >>> ClassPrepare event is received. >>> ? 362???????? synchronized void setHCRefType(ReferenceType type) { >>> ? 363???????????? hcRefType = type; >>> ? 364???????????? notifyAll(); >>> ? 365???????? } >>> ? 366 >>> ? 367???????? // This method is used by the debugger main thread to >>> wait and get >>> ? 368???????? // the hidden class reference type from its >>> ClassPrepare event. >>> ? 369???????? // The readyCmdSync with the debuggeee is not enough >>> because a >>> ? 370???????? // ClassPrepare event sent over JDWP protocol has some >>> delay. >>> ? 371???????? // A wait/notify sync is to ensure the debugger gets >>> non-null value. >>> ? 372???????? synchronized ReferenceType getHCRefType() { >>> ? 373???????????? try { >>> ? 374???????????????? while (hcRefType == null) { >>> ? 375???????????????????? wait(); >>> ? 376???????????????? } >>> ? 377???????????? } catch (InterruptedException ie) { >>> ? 378???????????????? throw new Failure("Unexpected >>> InterruptedException in waiting for HC prepare: " + ie); >>> ? 379???????????? } >>> ? 380???????????? return hcRefType; >>> ? 381???????? } >> >> Good suggestion - fixed. I've replaced getHCRefType with >> waitGetHCRefType. >> Also, I've removed all uses of Failure and InterruptedException >> catches and specified a couple of methods to throw InterruptedException. >> >>> >>> 10. We don't run tests with -ea/esa so assertions usually disabled. >>> Use Assertions from test lib instead. The comment 1) is >>> recommendation only but 'assert' is just ignored. >>> ? 436???????????? assert name.indexOf("HiddenClass") > 0 && >>> name.indexOf("/0x") > 0; >> >> Thanks - fixed. >> >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001a.java.html >>> >>> >>> >>> 11. Check if jdk.test.lib.classloader.ClassLoadUtils. >>> getClassPath(String className) works for you instead of >>> ?? 70???? private static String getClassPath(Class klass) { >>> >>> 12. You could use try(log = new PrintStream("Debuggee.log")) {} here: >>> ?? 82???????? log = new PrintStream("Debuggee.log"); >>> .. >>> ?? 86???????? try { >>> .. >>> ? ?90???????? } >>> ?? 91???????? log.close(); >> >> Good idea, but unfortunately it does not work as the field needs to >> be static. >> >> >>> 13. It is better to throw RuntimeException and don't add throws >>> Exception in all methods. >>> 95???? private void syncWithDebugger(IOPipe pipe) throws Exception { >> >> Good suggestion - fixed. >> >> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent/classUnloadEvent001a.java.html >>> >>> >>> You could use single if for this. >>> ? 122???????? if (command == null) { >>> ? 123???????????? throw new Exception("Failed: pipe.readln() >>> returned null instead of COMMAND_QUIT"); >>> ? 124???????? } else if >>> (!command.equals(classUnloadEvent001.COMMAND_QUIT)) { >>> ? 125???????????? throw new Exception("Failed COMMAND_QUIT sync with >>> debugger, got unknown command: " + command); >>> ? 126???????? } >> >> I wanted a separate error message for (command == null) as it was >> related to OOME on the debuggee side. >> But it is not important anymore after the WT.fullGC() is used. >> Fixed. >> >>> 14. Setting to null is not required to collect objects here. >>> 151???????? hcObj = null; >>> 152???????? hc = null; >> >> It is better to keep these to be sure the hidden class can be unloaded. >> I had to create one mode hidden class to get a ClassUnload event. >> There is a comment in the test debuggee explaining it. >> >> >>> Probably I didn't catch all issues, but let discuss this list first. >> >> Okay. >> >> Thanks! >> Serguei >> >>> Leonid >>> >>> On 4/23/20 9:01 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review a fix for the sub-task: >>>> https://bugs.openjdk.java.net/browse/JDK-8241807 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/ >>>> >>>> >>>> >>>> Summary; >>>> ? This sub-task is to cover any hidden class related remaining >>>> issues in the JDI and JDWP implementation. >>>> ? In fact, no more issues were discovered with this extra test >>>> coverage. >>>> ? So, this update includes only two new nsk jdi tests: >>>> || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent >>>> || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent >>>> >>>> ? These tests are to provide a test coverage? which was impossible >>>> to provide with the jdb testing framework. >>>> ? It includes ClassPrepare, Breakpoint and ModificationWatchpoint >>>> events with class filters. >>>> >>>> Testing: >>>> ? The mach5 job is in progress: >>>> https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jdi-event-tests-20200424-0350-10464032 >>>> >>>> >>>> Thanks, >>>> Serguei >> From alexey.menkov at oracle.com Wed Apr 29 01:14:56 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 28 Apr 2020 18:14:56 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: References: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> Message-ID: <775a66b3-b29f-d200-50f5-0625f5c6f802@oracle.com> On 04/28/2020 18:03, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > Thank you a lot for reviewing this. > > > On 4/28/20 17:35, Alex Menkov wrote: >> Hi Serguei, >> >> Looks good in general. >> couple minor notes: >> >> DebuggerBase.java >> >> - vm, debuggee, pipe and erManager fields and getDebuggee(), vm() >> methods don't need to be static; > > Thank you for the suggestion. > > The erManager and pipe are not static. Yes, you're right > It feels like you need to refresh the webrev pages as I've updated the > webrev in place a couple of times while waited for review. > > The vm() method is used in the EventHandler class which does not have a > reference to the DebuggerBase object. > It is why the vm() needs to be static. > The same is true for 4 other methods: getReferenceType(), findField(), > findMethod() and invokeStaticMethod(). > I was also thinking on how to get rid of this staic-ness and decided to > leave it alone. I'd pass DebuggeeBase instance to EventHandler.createAndStart() method. I don't like this fields static as they are initialized by non-static methods. --alex > > The getDebuggee() method is not used yet. > I've removed it. It is not a problem to add it back in case it is needed. > >> >> - replace all "imultiple" with "multiple". > > Nice catch - fixed. > > Thanks, > Serguei > >> >> --alex >> >> >> On 04/27/2020 18:34, serguei.spitsyn at oracle.com wrote: >>> Hi Leonid, >>> >>> Updated webrev version with the suggested refactoring is: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.5/ >>> >>> >>> >>> >>> >>> >>> Please, see my comments below. >>> >>> On 4/24/20 13:20, Leonid Mesnik wrote: >>>> >>>> Hi >>>> >>>> I have several comments about coding and desing. These tests might >>>> be used as examples for new JDI tests based on this framework so I >>>> think it would be better to polish them. >>>> >>> >>> Yes, as we agreed it'd be nice to create good examples, a base for a >>> future test development in the JDI area. >>> I also wanted to polish these tests as much as possible, so thanks >>> for helping with it. >>> These are good suggestions from you below. >>> One problem is that these tests will differ in style from the rest of >>> the NSK JDI tests but it has to be okay. >>> >>> >>>> General comment: >>>> >>>> 1. You often check results (not null, exactly one result). >>>> >>>> It makes sense to use jdk.test.lib.Asserts for such verification. >>>> Just to reduce number of code and fail with standard exceptions. >>>> >>> >>> Good suggestion - fixed now. >>> >>>> 2. Wildcard imports like 'import com.sun.jdi.*;' are not recommended. >>>> >>> >>> Good suggestion - fixed. >>> The list of imports became big but I see no problem with that. >>> >>>> 3. I recommend to catch Throwable instead of Exception especially in >>>> non-main threads. Just to ensure that nothing is missed. >>>> >>> >>> God suggestion - fixed, at least, in places where it makes sense to do. >>> >>>> 4. nsk.share.Failure is subclass of RuntimeException so you don't >>>> need to add it to throws. Now sometimes it is added, sometimes not. >>>> It looks inconsistent. >>>> >>> >>> Good suggestion - fixed. >>> In fact, I did not like the use of Failure as it creates this >>> inconsistency, so I tried to get rid of it. >>> >>>> 5. There are lot of code duplication in debugger and debugge >>>> classes. Does it make a sense to merge it into base classes? >>>> >>> >>> I was thinking about this too but was reluctant to do so, as there >>> are just two tests. >>> But it has to be beneficial to move shared code to the JDI testing >>> framework. >>> I've just made some initial preparation by separating common parts >>> DebuggeeBase and DebuggerBase. >>> Also, it seems to be natural to move the HiddenClass and EventHandler >>> classes to their own files. >>> Then I've decided to combine both tests into one. >>> All refactoring still makes sense to have. >>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001.java.html >>>> >>>> >>>> 6. The getField can't return null, it verifies result. So check in >>>> line 191-193 is not needed. >>>> >>>> ? 190???????? Field field = getField(hcRefType, "hcField"); >>>> ??191???????? if (field == null) { >>>> ? 192???????????? throw new Failure("TEST FAILED: cannot enable >>>> ModificationWhatchpointRequest: hcField not found"); >>>> ? 193???????? } >>> >>> Good catch - fixed. >>> >>>> >>>> 7. I would recommend to move all initialization from run in >>>> constructor and make most of variable 'final' it helps to ensure >>>> that they are initialized. >>>> ? 297???? public int run(final String args[], final PrintStream out) { >>>> ? 298???????? ArgumentHandler argHandler = new ArgumentHandler(args); >>>> ? 299 >>>> ? 300???????? log = new Log(out, argHandler); >>>> ? 301???????? eventTimeout = argHandler.getWaitTime() * 60 * 1000; >>>> // milliseconds >>>> ? 302???????? launchDebuggee(argHandler); >>> >>> Right comment in general, but I did not go with a constructor and >>> final fields. >>> Instead, I've just reorganized this a little bit. >>> There is a little base to refactor to the constructor because the >>> field "log" needs to be static and timeout can be local. >>> >>> >>>> 8. Pair looks inconsistent. start saves handler as class field while >>>> join use as parameter. >>>> 305???????????? startEventHandler(); >>>> 330???????????? joinEventHandler(eventHandler); >>>> >>>> I think that something like >>>> EventHandler eventHandler = startEventHandler(); >>>> joinEventHandler(eventHandler); >>>> looks better and restrict usage of eventHandler. You also migt move >>>> methods startEventHandler into EventHandler itself. >>> >>> Good suggestion - fixed. Moved both methods to the EventHandler class. >>> >>>> >>>> 9. I suggest to make setHCRefType private and rename getHCRefType to >>>> something like receiveHCRefType. To make more clear that it is not a >>>> simple getter, but method which wait for event. >>>> ? 361???????? // Save hidden class ReferenceType when its >>>> ClassPrepare event is received. >>>> ? 362???????? synchronized void setHCRefType(ReferenceType type) { >>>> ? 363???????????? hcRefType = type; >>>> ? 364???????????? notifyAll(); >>>> ? 365???????? } >>>> ? 366 >>>> ? 367???????? // This method is used by the debugger main thread to >>>> wait and get >>>> ? 368???????? // the hidden class reference type from its >>>> ClassPrepare event. >>>> ? 369???????? // The readyCmdSync with the debuggeee is not enough >>>> because a >>>> ? 370???????? // ClassPrepare event sent over JDWP protocol has some >>>> delay. >>>> ? 371???????? // A wait/notify sync is to ensure the debugger gets >>>> non-null value. >>>> ? 372???????? synchronized ReferenceType getHCRefType() { >>>> ? 373???????????? try { >>>> ? 374???????????????? while (hcRefType == null) { >>>> ? 375???????????????????? wait(); >>>> ? 376???????????????? } >>>> ? 377???????????? } catch (InterruptedException ie) { >>>> ? 378???????????????? throw new Failure("Unexpected >>>> InterruptedException in waiting for HC prepare: " + ie); >>>> ? 379???????????? } >>>> ? 380???????????? return hcRefType; >>>> ? 381???????? } >>> >>> Good suggestion - fixed. I've replaced getHCRefType with >>> waitGetHCRefType. >>> Also, I've removed all uses of Failure and InterruptedException >>> catches and specified a couple of methods to throw InterruptedException. >>> >>>> >>>> 10. We don't run tests with -ea/esa so assertions usually disabled. >>>> Use Assertions from test lib instead. The comment 1) is >>>> recommendation only but 'assert' is just ignored. >>>> ? 436???????????? assert name.indexOf("HiddenClass") > 0 && >>>> name.indexOf("/0x") > 0; >>> >>> Thanks - fixed. >>> >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001a.java.html >>>> >>>> >>>> >>>> 11. Check if jdk.test.lib.classloader.ClassLoadUtils. >>>> getClassPath(String className) works for you instead of >>>> ?? 70???? private static String getClassPath(Class klass) { >>>> >>>> 12. You could use try(log = new PrintStream("Debuggee.log")) {} here: >>>> ?? 82???????? log = new PrintStream("Debuggee.log"); >>>> .. >>>> ?? 86???????? try { >>>> .. >>>> ? ?90???????? } >>>> ?? 91???????? log.close(); >>> >>> Good idea, but unfortunately it does not work as the field needs to >>> be static. >>> >>> >>>> 13. It is better to throw RuntimeException and don't add throws >>>> Exception in all methods. >>>> 95???? private void syncWithDebugger(IOPipe pipe) throws Exception { >>> >>> Good suggestion - fixed. >>> >>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent/classUnloadEvent001a.java.html >>>> >>>> >>>> You could use single if for this. >>>> ? 122???????? if (command == null) { >>>> ? 123???????????? throw new Exception("Failed: pipe.readln() >>>> returned null instead of COMMAND_QUIT"); >>>> ? 124???????? } else if >>>> (!command.equals(classUnloadEvent001.COMMAND_QUIT)) { >>>> ? 125???????????? throw new Exception("Failed COMMAND_QUIT sync with >>>> debugger, got unknown command: " + command); >>>> ? 126???????? } >>> >>> I wanted a separate error message for (command == null) as it was >>> related to OOME on the debuggee side. >>> But it is not important anymore after the WT.fullGC() is used. >>> Fixed. >>> >>>> 14. Setting to null is not required to collect objects here. >>>> 151???????? hcObj = null; >>>> 152???????? hc = null; >>> >>> It is better to keep these to be sure the hidden class can be unloaded. >>> I had to create one mode hidden class to get a ClassUnload event. >>> There is a comment in the test debuggee explaining it. >>> >>> >>>> Probably I didn't catch all issues, but let discuss this list first. >>> >>> Okay. >>> >>> Thanks! >>> Serguei >>> >>>> Leonid >>>> >>>> On 4/23/20 9:01 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review a fix for the sub-task: >>>>> https://bugs.openjdk.java.net/browse/JDK-8241807 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/ >>>>> >>>>> >>>>> >>>>> Summary; >>>>> ? This sub-task is to cover any hidden class related remaining >>>>> issues in the JDI and JDWP implementation. >>>>> ? In fact, no more issues were discovered with this extra test >>>>> coverage. >>>>> ? So, this update includes only two new nsk jdi tests: >>>>> || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent >>>>> || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent >>>>> >>>>> ? These tests are to provide a test coverage? which was impossible >>>>> to provide with the jdb testing framework. >>>>> ? It includes ClassPrepare, Breakpoint and ModificationWatchpoint >>>>> events with class filters. >>>>> >>>>> Testing: >>>>> ? The mach5 job is in progress: >>>>> https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jdi-event-tests-20200424-0350-10464032 >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>> > From serguei.spitsyn at oracle.com Wed Apr 29 01:31:17 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Apr 2020 18:31:17 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: References: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> Message-ID: <72cf8c8a-0aca-a9f3-fbd9-85882efc33f2@oracle.com> Hi Alex, The updated webrev version is: http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.6/ I'll push it if you have no objections. Thanks, Serguei On 4/28/20 18:03, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > Thank you a lot for reviewing this. > > > On 4/28/20 17:35, Alex Menkov wrote: >> Hi Serguei, >> >> Looks good in general. >> couple minor notes: >> >> DebuggerBase.java >> >> - vm, debuggee, pipe and erManager fields and getDebuggee(), vm() >> methods don't need to be static; > > Thank you for the suggestion. > > The erManager and pipe are not static. > It feels like you need to refresh the webrev pages as I've updated the > webrev in place a couple of times while waited for review. > > The vm() method is used in the EventHandler class which does not have > a reference to the DebuggerBase object. > It is why the vm() needs to be static. > The same is true for 4 other methods: getReferenceType(), findField(), > findMethod() and invokeStaticMethod(). > I was also thinking on how to get rid of this staic-ness and decided > to leave it alone. > > The getDebuggee() method is not used yet. > I've removed it. It is not a problem to add it back in case it is needed. > >> >> - replace all "imultiple" with "multiple". > > Nice catch - fixed. > > Thanks, > Serguei > >> >> --alex >> >> >> On 04/27/2020 18:34, serguei.spitsyn at oracle.com wrote: >>> Hi Leonid, >>> >>> Updated webrev version with the suggested refactoring is: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.5/ >>> >>> >>> >>> >>> >>> >>> Please, see my comments below. >>> >>> On 4/24/20 13:20, Leonid Mesnik wrote: >>>> >>>> Hi >>>> >>>> I have several comments about coding and desing. These tests might >>>> be used as examples for new JDI tests based on this framework so I >>>> think it would be better to polish them. >>>> >>> >>> Yes, as we agreed it'd be nice to create good examples, a base for a >>> future test development in the JDI area. >>> I also wanted to polish these tests as much as possible, so thanks >>> for helping with it. >>> These are good suggestions from you below. >>> One problem is that these tests will differ in style from the rest >>> of the NSK JDI tests but it has to be okay. >>> >>> >>>> General comment: >>>> >>>> 1. You often check results (not null, exactly one result). >>>> >>>> It makes sense to use jdk.test.lib.Asserts for such verification. >>>> Just to reduce number of code and fail with standard exceptions. >>>> >>> >>> Good suggestion - fixed now. >>> >>>> 2. Wildcard imports like 'import com.sun.jdi.*;' are not recommended. >>>> >>> >>> Good suggestion - fixed. >>> The list of imports became big but I see no problem with that. >>> >>>> 3. I recommend to catch Throwable instead of Exception especially >>>> in non-main threads. Just to ensure that nothing is missed. >>>> >>> >>> God suggestion - fixed, at least, in places where it makes sense to do. >>> >>>> 4. nsk.share.Failure is subclass of RuntimeException so you don't >>>> need to add it to throws. Now sometimes it is added, sometimes not. >>>> It looks inconsistent. >>>> >>> >>> Good suggestion - fixed. >>> In fact, I did not like the use of Failure as it creates this >>> inconsistency, so I tried to get rid of it. >>> >>>> 5. There are lot of code duplication in debugger and debugge >>>> classes. Does it make a sense to merge it into base classes? >>>> >>> >>> I was thinking about this too but was reluctant to do so, as there >>> are just two tests. >>> But it has to be beneficial to move shared code to the JDI testing >>> framework. >>> I've just made some initial preparation by separating common parts >>> DebuggeeBase and DebuggerBase. >>> Also, it seems to be natural to move the HiddenClass and >>> EventHandler classes to their own files. >>> Then I've decided to combine both tests into one. >>> All refactoring still makes sense to have. >>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001.java.html >>>> >>>> >>>> 6. The getField can't return null, it verifies result. So check in >>>> line 191-193 is not needed. >>>> >>>> ? 190???????? Field field = getField(hcRefType, "hcField"); >>>> ??191???????? if (field == null) { >>>> ? 192???????????? throw new Failure("TEST FAILED: cannot enable >>>> ModificationWhatchpointRequest: hcField not found"); >>>> ? 193???????? } >>> >>> Good catch - fixed. >>> >>>> >>>> 7. I would recommend to move all initialization from run in >>>> constructor and make most of variable 'final' it helps to ensure >>>> that they are initialized. >>>> ? 297???? public int run(final String args[], final PrintStream out) { >>>> ? 298???????? ArgumentHandler argHandler = new ArgumentHandler(args); >>>> ? 299 >>>> ? 300???????? log = new Log(out, argHandler); >>>> ? 301???????? eventTimeout = argHandler.getWaitTime() * 60 * 1000; >>>> // milliseconds >>>> ? 302???????? launchDebuggee(argHandler); >>> >>> Right comment in general, but I did not go with a constructor and >>> final fields. >>> Instead, I've just reorganized this a little bit. >>> There is a little base to refactor to the constructor because the >>> field "log" needs to be static and timeout can be local. >>> >>> >>>> 8. Pair looks inconsistent. start saves handler as class field >>>> while join use as parameter. >>>> 305???????????? startEventHandler(); >>>> 330???????????? joinEventHandler(eventHandler); >>>> >>>> I think that something like >>>> EventHandler eventHandler = startEventHandler(); >>>> joinEventHandler(eventHandler); >>>> looks better and restrict usage of eventHandler. You also migt move >>>> methods startEventHandler into EventHandler itself. >>> >>> Good suggestion - fixed. Moved both methods to the EventHandler class. >>> >>>> >>>> 9. I suggest to make setHCRefType private and rename getHCRefType >>>> to something like receiveHCRefType. To make more clear that it is >>>> not a simple getter, but method which wait for event. >>>> ? 361???????? // Save hidden class ReferenceType when its >>>> ClassPrepare event is received. >>>> ? 362???????? synchronized void setHCRefType(ReferenceType type) { >>>> ? 363???????????? hcRefType = type; >>>> ? 364???????????? notifyAll(); >>>> ? 365???????? } >>>> ? 366 >>>> ? 367???????? // This method is used by the debugger main thread to >>>> wait and get >>>> ? 368???????? // the hidden class reference type from its >>>> ClassPrepare event. >>>> ? 369???????? // The readyCmdSync with the debuggeee is not enough >>>> because a >>>> ? 370???????? // ClassPrepare event sent over JDWP protocol has >>>> some delay. >>>> ? 371???????? // A wait/notify sync is to ensure the debugger gets >>>> non-null value. >>>> ? 372???????? synchronized ReferenceType getHCRefType() { >>>> ? 373???????????? try { >>>> ? 374???????????????? while (hcRefType == null) { >>>> ? 375???????????????????? wait(); >>>> ? 376???????????????? } >>>> ? 377???????????? } catch (InterruptedException ie) { >>>> ? 378???????????????? throw new Failure("Unexpected >>>> InterruptedException in waiting for HC prepare: " + ie); >>>> ? 379???????????? } >>>> ? 380???????????? return hcRefType; >>>> ? 381???????? } >>> >>> Good suggestion - fixed. I've replaced getHCRefType with >>> waitGetHCRefType. >>> Also, I've removed all uses of Failure and InterruptedException >>> catches and specified a couple of methods to throw >>> InterruptedException. >>> >>>> >>>> 10. We don't run tests with -ea/esa so assertions usually disabled. >>>> Use Assertions from test lib instead. The comment 1) is >>>> recommendation only but 'assert' is just ignored. >>>> ? 436???????????? assert name.indexOf("HiddenClass") > 0 && >>>> name.indexOf("/0x") > 0; >>> >>> Thanks - fixed. >>> >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001a.java.html >>>> >>>> >>>> >>>> 11. Check if jdk.test.lib.classloader.ClassLoadUtils. >>>> getClassPath(String className) works for you instead of >>>> ?? 70???? private static String getClassPath(Class klass) { >>>> >>>> 12. You could use try(log = new PrintStream("Debuggee.log")) {} here: >>>> ?? 82???????? log = new PrintStream("Debuggee.log"); >>>> .. >>>> ?? 86???????? try { >>>> .. >>>> ? ?90???????? } >>>> ?? 91???????? log.close(); >>> >>> Good idea, but unfortunately it does not work as the field needs to >>> be static. >>> >>> >>>> 13. It is better to throw RuntimeException and don't add throws >>>> Exception in all methods. >>>> 95???? private void syncWithDebugger(IOPipe pipe) throws Exception { >>> >>> Good suggestion - fixed. >>> >>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent/classUnloadEvent001a.java.html >>>> >>>> >>>> You could use single if for this. >>>> ? 122???????? if (command == null) { >>>> ? 123???????????? throw new Exception("Failed: pipe.readln() >>>> returned null instead of COMMAND_QUIT"); >>>> ? 124???????? } else if >>>> (!command.equals(classUnloadEvent001.COMMAND_QUIT)) { >>>> ? 125???????????? throw new Exception("Failed COMMAND_QUIT sync >>>> with debugger, got unknown command: " + command); >>>> ? 126???????? } >>> >>> I wanted a separate error message for (command == null) as it was >>> related to OOME on the debuggee side. >>> But it is not important anymore after the WT.fullGC() is used. >>> Fixed. >>> >>>> 14. Setting to null is not required to collect objects here. >>>> 151???????? hcObj = null; >>>> 152???????? hc = null; >>> >>> It is better to keep these to be sure the hidden class can be unloaded. >>> I had to create one mode hidden class to get a ClassUnload event. >>> There is a comment in the test debuggee explaining it. >>> >>> >>>> Probably I didn't catch all issues, but let discuss this list first. >>> >>> Okay. >>> >>> Thanks! >>> Serguei >>> >>>> Leonid >>>> >>>> On 4/23/20 9:01 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review a fix for the sub-task: >>>>> https://bugs.openjdk.java.net/browse/JDK-8241807 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/ >>>>> >>>>> >>>>> >>>>> Summary; >>>>> ? This sub-task is to cover any hidden class related remaining >>>>> issues in the JDI and JDWP implementation. >>>>> ? In fact, no more issues were discovered with this extra test >>>>> coverage. >>>>> ? So, this update includes only two new nsk jdi tests: >>>>> || >>>>> test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent >>>>> || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent >>>>> >>>>> ? These tests are to provide a test coverage? which was impossible >>>>> to provide with the jdb testing framework. >>>>> ? It includes ClassPrepare, Breakpoint and ModificationWatchpoint >>>>> events with class filters. >>>>> >>>>> Testing: >>>>> ? The mach5 job is in progress: >>>>> https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jdi-event-tests-20200424-0350-10464032 >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>> > From serguei.spitsyn at oracle.com Wed Apr 29 02:17:00 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Apr 2020 19:17:00 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: <775a66b3-b29f-d200-50f5-0625f5c6f802@oracle.com> References: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> <775a66b3-b29f-d200-50f5-0625f5c6f802@oracle.com> Message-ID: <815140fd-2a2d-6818-7c8b-b56153f437d8@oracle.com> On 4/28/20 18:14, Alex Menkov wrote: > > > On 04/28/2020 18:03, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> Thank you a lot for reviewing this. >> >> >> On 4/28/20 17:35, Alex Menkov wrote: >>> Hi Serguei, >>> >>> Looks good in general. >>> couple minor notes: >>> >>> DebuggerBase.java >>> >>> - vm, debuggee, pipe and erManager fields and getDebuggee(), vm() >>> methods don't need to be static; >> >> Thank you for the suggestion. >> >> The erManager and pipe are not static. > > Yes, you're right > >> It feels like you need to refresh the webrev pages as I've updated >> the webrev in place a couple of times while waited for review. >> >> The vm() method is used in the EventHandler class which does not have >> a reference to the DebuggerBase object. >> It is why the vm() needs to be static. >> The same is true for 4 other methods: getReferenceType(), >> findField(), findMethod() and invokeStaticMethod(). >> I was also thinking on how to get rid of this staic-ness and decided >> to leave it alone. > > I'd pass DebuggeeBase instance to EventHandler.createAndStart() method. > I don't like this fields static as they are initialized by non-static > methods. Nice suggestion. I also do not like the static fields initialized by non static methods. I was also thinking about it. Thanks! Serguei > --alex > >> >> The getDebuggee() method is not used yet. >> I've removed it. It is not a problem to add it back in case it is >> needed. >> >>> >>> - replace all "imultiple" with "multiple". >> >> Nice catch - fixed. >> >> Thanks, >> Serguei >> >>> >>> --alex >>> >>> >>> On 04/27/2020 18:34, serguei.spitsyn at oracle.com wrote: >>>> Hi Leonid, >>>> >>>> Updated webrev version with the suggested refactoring is: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.5/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> Please, see my comments below. >>>> >>>> On 4/24/20 13:20, Leonid Mesnik wrote: >>>>> >>>>> Hi >>>>> >>>>> I have several comments about coding and desing. These tests might >>>>> be used as examples for new JDI tests based on this framework so I >>>>> think it would be better to polish them. >>>>> >>>> >>>> Yes, as we agreed it'd be nice to create good examples, a base for >>>> a future test development in the JDI area. >>>> I also wanted to polish these tests as much as possible, so thanks >>>> for helping with it. >>>> These are good suggestions from you below. >>>> One problem is that these tests will differ in style from the rest >>>> of the NSK JDI tests but it has to be okay. >>>> >>>> >>>>> General comment: >>>>> >>>>> 1. You often check results (not null, exactly one result). >>>>> >>>>> It makes sense to use jdk.test.lib.Asserts for such verification. >>>>> Just to reduce number of code and fail with standard exceptions. >>>>> >>>> >>>> Good suggestion - fixed now. >>>> >>>>> 2. Wildcard imports like 'import com.sun.jdi.*;' are not recommended. >>>>> >>>> >>>> Good suggestion - fixed. >>>> The list of imports became big but I see no problem with that. >>>> >>>>> 3. I recommend to catch Throwable instead of Exception especially >>>>> in non-main threads. Just to ensure that nothing is missed. >>>>> >>>> >>>> God suggestion - fixed, at least, in places where it makes sense to >>>> do. >>>> >>>>> 4. nsk.share.Failure is subclass of RuntimeException so you don't >>>>> need to add it to throws. Now sometimes it is added, sometimes >>>>> not. It looks inconsistent. >>>>> >>>> >>>> Good suggestion - fixed. >>>> In fact, I did not like the use of Failure as it creates this >>>> inconsistency, so I tried to get rid of it. >>>> >>>>> 5. There are lot of code duplication in debugger and debugge >>>>> classes. Does it make a sense to merge it into base classes? >>>>> >>>> >>>> I was thinking about this too but was reluctant to do so, as there >>>> are just two tests. >>>> But it has to be beneficial to move shared code to the JDI testing >>>> framework. >>>> I've just made some initial preparation by separating common parts >>>> DebuggeeBase and DebuggerBase. >>>> Also, it seems to be natural to move the HiddenClass and >>>> EventHandler classes to their own files. >>>> Then I've decided to combine both tests into one. >>>> All refactoring still makes sense to have. >>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001.java.html >>>>> >>>>> >>>>> 6. The getField can't return null, it verifies result. So check in >>>>> line 191-193 is not needed. >>>>> >>>>> ? 190???????? Field field = getField(hcRefType, "hcField"); >>>>> ??191???????? if (field == null) { >>>>> ? 192???????????? throw new Failure("TEST FAILED: cannot enable >>>>> ModificationWhatchpointRequest: hcField not found"); >>>>> ? 193???????? } >>>> >>>> Good catch - fixed. >>>> >>>>> >>>>> 7. I would recommend to move all initialization from run in >>>>> constructor and make most of variable 'final' it helps to ensure >>>>> that they are initialized. >>>>> ? 297???? public int run(final String args[], final PrintStream >>>>> out) { >>>>> ? 298???????? ArgumentHandler argHandler = new ArgumentHandler(args); >>>>> ? 299 >>>>> ? 300???????? log = new Log(out, argHandler); >>>>> ? 301???????? eventTimeout = argHandler.getWaitTime() * 60 * 1000; >>>>> // milliseconds >>>>> ? 302???????? launchDebuggee(argHandler); >>>> >>>> Right comment in general, but I did not go with a constructor and >>>> final fields. >>>> Instead, I've just reorganized this a little bit. >>>> There is a little base to refactor to the constructor because the >>>> field "log" needs to be static and timeout can be local. >>>> >>>> >>>>> 8. Pair looks inconsistent. start saves handler as class field >>>>> while join use as parameter. >>>>> 305???????????? startEventHandler(); >>>>> 330???????????? joinEventHandler(eventHandler); >>>>> >>>>> I think that something like >>>>> EventHandler eventHandler = startEventHandler(); >>>>> joinEventHandler(eventHandler); >>>>> looks better and restrict usage of eventHandler. You also migt >>>>> move methods startEventHandler into EventHandler itself. >>>> >>>> Good suggestion - fixed. Moved both methods to the EventHandler class. >>>> >>>>> >>>>> 9. I suggest to make setHCRefType private and rename getHCRefType >>>>> to something like receiveHCRefType. To make more clear that it is >>>>> not a simple getter, but method which wait for event. >>>>> ? 361???????? // Save hidden class ReferenceType when its >>>>> ClassPrepare event is received. >>>>> ? 362???????? synchronized void setHCRefType(ReferenceType type) { >>>>> ? 363???????????? hcRefType = type; >>>>> ? 364???????????? notifyAll(); >>>>> ? 365???????? } >>>>> ? 366 >>>>> ? 367???????? // This method is used by the debugger main thread >>>>> to wait and get >>>>> ? 368???????? // the hidden class reference type from its >>>>> ClassPrepare event. >>>>> ? 369???????? // The readyCmdSync with the debuggeee is not enough >>>>> because a >>>>> ? 370???????? // ClassPrepare event sent over JDWP protocol has >>>>> some delay. >>>>> ? 371???????? // A wait/notify sync is to ensure the debugger gets >>>>> non-null value. >>>>> ? 372???????? synchronized ReferenceType getHCRefType() { >>>>> ? 373???????????? try { >>>>> ? 374???????????????? while (hcRefType == null) { >>>>> ? 375???????????????????? wait(); >>>>> ? 376???????????????? } >>>>> ? 377???????????? } catch (InterruptedException ie) { >>>>> ? 378???????????????? throw new Failure("Unexpected >>>>> InterruptedException in waiting for HC prepare: " + ie); >>>>> ? 379???????????? } >>>>> ? 380???????????? return hcRefType; >>>>> ? 381???????? } >>>> >>>> Good suggestion - fixed. I've replaced getHCRefType with >>>> waitGetHCRefType. >>>> Also, I've removed all uses of Failure and InterruptedException >>>> catches and specified a couple of methods to throw >>>> InterruptedException. >>>> >>>>> >>>>> 10. We don't run tests with -ea/esa so assertions usually >>>>> disabled. Use Assertions from test lib instead. The comment 1) is >>>>> recommendation only but 'assert' is just ignored. >>>>> ? 436???????????? assert name.indexOf("HiddenClass") > 0 && >>>>> name.indexOf("/0x") > 0; >>>> >>>> Thanks - fixed. >>>> >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001a.java.html >>>>> >>>>> >>>>> >>>>> 11. Check if jdk.test.lib.classloader.ClassLoadUtils. >>>>> getClassPath(String className) works for you instead of >>>>> ?? 70???? private static String getClassPath(Class klass) { >>>>> >>>>> 12. You could use try(log = new PrintStream("Debuggee.log")) {} here: >>>>> ?? 82???????? log = new PrintStream("Debuggee.log"); >>>>> .. >>>>> ?? 86???????? try { >>>>> .. >>>>> ? ?90???????? } >>>>> ?? 91???????? log.close(); >>>> >>>> Good idea, but unfortunately it does not work as the field needs to >>>> be static. >>>> >>>> >>>>> 13. It is better to throw RuntimeException and don't add throws >>>>> Exception in all methods. >>>>> 95???? private void syncWithDebugger(IOPipe pipe) throws Exception { >>>> >>>> Good suggestion - fixed. >>>> >>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent/classUnloadEvent001a.java.html >>>>> >>>>> >>>>> You could use single if for this. >>>>> ? 122???????? if (command == null) { >>>>> ? 123???????????? throw new Exception("Failed: pipe.readln() >>>>> returned null instead of COMMAND_QUIT"); >>>>> ? 124???????? } else if >>>>> (!command.equals(classUnloadEvent001.COMMAND_QUIT)) { >>>>> ? 125???????????? throw new Exception("Failed COMMAND_QUIT sync >>>>> with debugger, got unknown command: " + command); >>>>> ? 126???????? } >>>> >>>> I wanted a separate error message for (command == null) as it was >>>> related to OOME on the debuggee side. >>>> But it is not important anymore after the WT.fullGC() is used. >>>> Fixed. >>>> >>>>> 14. Setting to null is not required to collect objects here. >>>>> 151???????? hcObj = null; >>>>> 152???????? hc = null; >>>> >>>> It is better to keep these to be sure the hidden class can be >>>> unloaded. >>>> I had to create one mode hidden class to get a ClassUnload event. >>>> There is a comment in the test debuggee explaining it. >>>> >>>> >>>>> Probably I didn't catch all issues, but let discuss this list first. >>>> >>>> Okay. >>>> >>>> Thanks! >>>> Serguei >>>> >>>>> Leonid >>>>> >>>>> On 4/23/20 9:01 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review a fix for the sub-task: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8241807 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/ >>>>>> >>>>>> >>>>>> >>>>>> Summary; >>>>>> ? This sub-task is to cover any hidden class related remaining >>>>>> issues in the JDI and JDWP implementation. >>>>>> ? In fact, no more issues were discovered with this extra test >>>>>> coverage. >>>>>> ? So, this update includes only two new nsk jdi tests: >>>>>> || >>>>>> test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent >>>>>> || >>>>>> test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent >>>>>> >>>>>> ? These tests are to provide a test coverage? which was >>>>>> impossible to provide with the jdb testing framework. >>>>>> ? It includes ClassPrepare, Breakpoint and ModificationWatchpoint >>>>>> events with class filters. >>>>>> >>>>>> Testing: >>>>>> ? The mach5 job is in progress: >>>>>> https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jdi-event-tests-20200424-0350-10464032 >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >> From igor.ignatyev at oracle.com Wed Apr 29 03:20:34 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 28 Apr 2020 20:20:34 -0700 Subject: RFR(T) : 8244052 : remove copying of s.h.WB$WhiteBoxPermission in test/jdk Message-ID: http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/ > 34 lines changed: 0 ins; 11 del; 23 mod; Hi all, could you please review this trivial patch? from JBS: > JDK-8199290 made it unnecessary to explicitly pass sun.hotspot.WhiteBox$WhiteBoxPermission as an argument to ClassFileInstaller b/c the former now copies it every time it copies sun.hotspot.WhiteBox. besides removing WhiteBoxPermission from the list of ClassFileInstaller's arguments, the patch also makes sure ClassFileInstaller is run in a driver mode in all the touched tests. testing: the changed tests webrev: http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8244052 Thanks, -- Igor From david.holmes at oracle.com Wed Apr 29 06:28:50 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Apr 2020 16:28:50 +1000 Subject: RFR(T) : 8244052 : remove copying of s.h.WB$WhiteBoxPermission in test/jdk In-Reply-To: References: Message-ID: <5c3ad29f-5a32-63f9-ab43-b7f41b57df23@oracle.com> Looks good! Thanks, David On 29/04/2020 1:20 pm, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/ >> 34 lines changed: 0 ins; 11 del; 23 mod; > > Hi all, > > could you please review this trivial patch? > from JBS: >> JDK-8199290 made it unnecessary to explicitly pass sun.hotspot.WhiteBox$WhiteBoxPermission as an argument to ClassFileInstaller b/c the former now copies it every time it copies sun.hotspot.WhiteBox. > > besides removing WhiteBoxPermission from the list of ClassFileInstaller's arguments, the patch also makes sure ClassFileInstaller is run in a driver mode in all the touched tests. > > testing: the changed tests > webrev: http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8244052 > > Thanks, > -- Igor > From serguei.spitsyn at oracle.com Wed Apr 29 06:39:42 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Apr 2020 23:39:42 -0700 Subject: RFR(T) : 8244052 : remove copying of s.h.WB$WhiteBoxPermission in test/jdk In-Reply-To: <5c3ad29f-5a32-63f9-ab43-b7f41b57df23@oracle.com> References: <5c3ad29f-5a32-63f9-ab43-b7f41b57df23@oracle.com> Message-ID: <8a2ba3d0-58f4-c881-5970-af5509babb91@oracle.com> LGTM++ Thanks, Serguei On 4/28/20 23:28, David Holmes wrote: > Looks good! > > Thanks, > David > > On 29/04/2020 1:20 pm, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/ >>> 34 lines changed: 0 ins; 11 del; 23 mod; >> >> Hi all, >> >> could you please review this trivial patch? >> from JBS: >>> JDK-8199290 made it unnecessary to explicitly pass >>> sun.hotspot.WhiteBox$WhiteBoxPermission as an argument to >>> ClassFileInstaller b/c the former now copies it every time it copies >>> sun.hotspot.WhiteBox. >> >> besides removing WhiteBoxPermission from the list of >> ClassFileInstaller's arguments, the patch also makes sure >> ClassFileInstaller is run in a driver mode in all the touched tests. >> >> testing: the changed tests >> webrev: http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244052 >> >> Thanks, >> -- Igor >> From chris.plummer at oracle.com Wed Apr 29 06:44:07 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 28 Apr 2020 23:44:07 -0700 Subject: RFR(T) : 8243929 : use @requires in serviceability/attach/AttachWithStalePidFile.java test In-Reply-To: <2CD34808-4130-4AAC-8861-90FC999B2744@oracle.com> References: <2CD34808-4130-4AAC-8861-90FC999B2744@oracle.com> Message-ID: Hi Igor, Looks good except copyright needs updating. cheers, Chris On 4/27/20 4:58 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8243929/webrev.00 >> 7 lines changed: 1 ins; 6 del; 0 mod; > Hi all, > > could you please review this trivial patch which updates AttachWithStalePidFile.java test to use @requires? > from JBS: >> serviceability/attach/AttachWithStalePidFile.java test can be run on windows and checks platform before executing any actual testing code. the modern faster and cleaner way to do it is using @requires. > JBS: https://bugs.openjdk.java.net/browse/JDK-8243929 > webrev: http://cr.openjdk.java.net/~iignatyev//8243929/webrev.00 > > Thanks, > -- Igor > From chris.plummer at oracle.com Wed Apr 29 06:49:37 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 28 Apr 2020 23:49:37 -0700 Subject: RFR: JDK-8242522: Minor LingeredApp improvements In-Reply-To: <103ac919-26de-67fa-0872-c1b06c5df20d@oracle.com> References: <619494c6-4b0e-1c38-d9e4-2e57a511377a@oracle.com> <8341e8f7-8944-1dfd-6891-1846082fa5fe@oracle.com> <103ac919-26de-67fa-0872-c1b06c5df20d@oracle.com> Message-ID: Hi Alex, Looks good except for one minor nit: ?249???????????? if (epoch - here > (timeout)) { No needs for the parens around "timeout". I don't need to see another webrev. thanks, Chris On 4/27/20 5:36 PM, Alex Menkov wrote: > updated webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev.2/ > > Moved getStdoutAsList to OutputBuffer. > > --alex > > On 04/24/2020 20:38, Chris Plummer wrote: >> On 4/24/20 6:52 PM, Alex Menkov wrote: >>> Hi Chris, >>> >>> On 04/24/2020 15:42, Chris Plummer wrote: >>>> Hi Alex, >>>> >>>> Overall it looks good, although I'm not so sure I agree with >>>> removing getAppOutput(). It's a generally useful utility API. Seems >>>> it is better off in LingeredApp.java rather than in the one test >>>> that currently uses it. >>> >>> To me the method just adds noise to the class. >>> If you think it can be useful for some other tests, I'd move it to >>> to OutputBuffer (make it default method which uses >>> OutputBuffer.getStdout()): >>> >>> default public List getStdOutAsList() >> I think that's a good idea. It looks like what tests are commonly >> doing now is using String.split(): >> >> ???????????? String[] appLines?? = >> app.getOutput().getStdout().split("\\R"); >> >> I'm not sure of the pros and cons of producing a String[] this way vs >> a List using getStdOutAsList(). Maybe both have their uses. >> But one thing for sure is the split() code is a lot more readable. >> One reason I prefer getStdOutAsList() being placed in a library or >> utility class is because TBH I find Streams code very hard to read, >> and combining with chained Reader code doesn't help any, so I just >> assume it be in a library that I'm less apt to look at rather than in >> the test where I'm bound to find my eyes glazing over as I'm drawn in >> to figure it out. >> >> Chris >>> >>> --alex >>> >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 4/24/20 3:17 PM, Alex Menkov wrote: >>>>> Hi all, >>>>> >>>>> Please review the fix for >>>>> https://bugs.openjdk.java.net/browse/JDK-8242522 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev/ >>>>> >>>>> The fix contains minor fixes/improvements for LingeredApp and >>>>> tests which use it. See jira for details. >>>>> >>>>> Tested all tests which use LingeredApp. >>>>> >>>>> --alex >>>> >> >> From igor.ignatyev at oracle.com Wed Apr 29 13:58:48 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 29 Apr 2020 06:58:48 -0700 Subject: RFR(T) : 8243929 : use @requires in serviceability/attach/AttachWithStalePidFile.java test In-Reply-To: References: <2CD34808-4130-4AAC-8861-90FC999B2744@oracle.com> Message-ID: <0BC564D5-D45C-4534-9A8B-B407A81F01EE@oracle.com> Hi Chris, thanks for review. sure I'll update the copyright before pushing. -- Igor > On Apr 28, 2020, at 11:44 PM, Chris Plummer wrote: > > Hi Igor, > > Looks good except copyright needs updating. > > cheers, > > Chris > > On 4/27/20 4:58 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8243929/webrev.00 >>> 7 lines changed: 1 ins; 6 del; 0 mod; >> Hi all, >> >> could you please review this trivial patch which updates AttachWithStalePidFile.java test to use @requires? >> from JBS: >>> serviceability/attach/AttachWithStalePidFile.java test can be run on windows and checks platform before executing any actual testing code. the modern faster and cleaner way to do it is using @requires. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8243929 >> webrev: http://cr.openjdk.java.net/~iignatyev//8243929/webrev.00 >> >> Thanks, >> -- Igor >> > From igor.ignatyev at oracle.com Wed Apr 29 14:09:14 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 29 Apr 2020 07:09:14 -0700 Subject: RFR(T) : 8244052 : remove copying of s.h.WB$WhiteBoxPermission in test/jdk In-Reply-To: <8a2ba3d0-58f4-c881-5970-af5509babb91@oracle.com> References: <5c3ad29f-5a32-63f9-ab43-b7f41b57df23@oracle.com> <8a2ba3d0-58f4-c881-5970-af5509babb91@oracle.com> Message-ID: <5120B327-E3C1-46DD-8E35-572A00069C6E@oracle.com> Serguei, David, thanks for your reviews. pushed. -- Igor > On Apr 28, 2020, at 11:39 PM, serguei.spitsyn at oracle.com wrote: > > LGTM++ > > Thanks, > Serguei > > > On 4/28/20 23:28, David Holmes wrote: >> Looks good! >> >> Thanks, >> David >> >> On 29/04/2020 1:20 pm, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/ >>>> 34 lines changed: 0 ins; 11 del; 23 mod; >>> >>> Hi all, >>> >>> could you please review this trivial patch? >>> from JBS: >>>> JDK-8199290 made it unnecessary to explicitly pass sun.hotspot.WhiteBox$WhiteBoxPermission as an argument to ClassFileInstaller b/c the former now copies it every time it copies sun.hotspot.WhiteBox. >>> >>> besides removing WhiteBoxPermission from the list of ClassFileInstaller's arguments, the patch also makes sure ClassFileInstaller is run in a driver mode in all the touched tests. >>> >>> testing: the changed tests >>> webrev: http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244052 >>> >>> Thanks, >>> -- Igor >>> > From alexey.menkov at oracle.com Wed Apr 29 19:21:00 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 29 Apr 2020 12:21:00 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: <72cf8c8a-0aca-a9f3-fbd9-85882efc33f2@oracle.com> References: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> <72cf8c8a-0aca-a9f3-fbd9-85882efc33f2@oracle.com> Message-ID: LGTM --alex On 04/28/2020 18:31, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > The updated webrev version is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.6/ > > I'll push it if you have no objections. > > Thanks, > Serguei > > > > On 4/28/20 18:03, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> Thank you a lot for reviewing this. >> >> >> On 4/28/20 17:35, Alex Menkov wrote: >>> Hi Serguei, >>> >>> Looks good in general. >>> couple minor notes: >>> >>> DebuggerBase.java >>> >>> - vm, debuggee, pipe and erManager fields and getDebuggee(), vm() >>> methods don't need to be static; >> >> Thank you for the suggestion. >> >> The erManager and pipe are not static. >> It feels like you need to refresh the webrev pages as I've updated the >> webrev in place a couple of times while waited for review. >> >> The vm() method is used in the EventHandler class which does not have >> a reference to the DebuggerBase object. >> It is why the vm() needs to be static. >> The same is true for 4 other methods: getReferenceType(), findField(), >> findMethod() and invokeStaticMethod(). >> I was also thinking on how to get rid of this staic-ness and decided >> to leave it alone. >> >> The getDebuggee() method is not used yet. >> I've removed it. It is not a problem to add it back in case it is needed. >> >>> >>> - replace all "imultiple" with "multiple". >> >> Nice catch - fixed. >> >> Thanks, >> Serguei >> >>> >>> --alex >>> >>> >>> On 04/27/2020 18:34, serguei.spitsyn at oracle.com wrote: >>>> Hi Leonid, >>>> >>>> Updated webrev version with the suggested refactoring is: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.5/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> Please, see my comments below. >>>> >>>> On 4/24/20 13:20, Leonid Mesnik wrote: >>>>> >>>>> Hi >>>>> >>>>> I have several comments about coding and desing. These tests might >>>>> be used as examples for new JDI tests based on this framework so I >>>>> think it would be better to polish them. >>>>> >>>> >>>> Yes, as we agreed it'd be nice to create good examples, a base for a >>>> future test development in the JDI area. >>>> I also wanted to polish these tests as much as possible, so thanks >>>> for helping with it. >>>> These are good suggestions from you below. >>>> One problem is that these tests will differ in style from the rest >>>> of the NSK JDI tests but it has to be okay. >>>> >>>> >>>>> General comment: >>>>> >>>>> 1. You often check results (not null, exactly one result). >>>>> >>>>> It makes sense to use jdk.test.lib.Asserts for such verification. >>>>> Just to reduce number of code and fail with standard exceptions. >>>>> >>>> >>>> Good suggestion - fixed now. >>>> >>>>> 2. Wildcard imports like 'import com.sun.jdi.*;' are not recommended. >>>>> >>>> >>>> Good suggestion - fixed. >>>> The list of imports became big but I see no problem with that. >>>> >>>>> 3. I recommend to catch Throwable instead of Exception especially >>>>> in non-main threads. Just to ensure that nothing is missed. >>>>> >>>> >>>> God suggestion - fixed, at least, in places where it makes sense to do. >>>> >>>>> 4. nsk.share.Failure is subclass of RuntimeException so you don't >>>>> need to add it to throws. Now sometimes it is added, sometimes not. >>>>> It looks inconsistent. >>>>> >>>> >>>> Good suggestion - fixed. >>>> In fact, I did not like the use of Failure as it creates this >>>> inconsistency, so I tried to get rid of it. >>>> >>>>> 5. There are lot of code duplication in debugger and debugge >>>>> classes. Does it make a sense to merge it into base classes? >>>>> >>>> >>>> I was thinking about this too but was reluctant to do so, as there >>>> are just two tests. >>>> But it has to be beneficial to move shared code to the JDI testing >>>> framework. >>>> I've just made some initial preparation by separating common parts >>>> DebuggeeBase and DebuggerBase. >>>> Also, it seems to be natural to move the HiddenClass and >>>> EventHandler classes to their own files. >>>> Then I've decided to combine both tests into one. >>>> All refactoring still makes sense to have. >>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001.java.html >>>>> >>>>> >>>>> 6. The getField can't return null, it verifies result. So check in >>>>> line 191-193 is not needed. >>>>> >>>>> ? 190???????? Field field = getField(hcRefType, "hcField"); >>>>> ??191???????? if (field == null) { >>>>> ? 192???????????? throw new Failure("TEST FAILED: cannot enable >>>>> ModificationWhatchpointRequest: hcField not found"); >>>>> ? 193???????? } >>>> >>>> Good catch - fixed. >>>> >>>>> >>>>> 7. I would recommend to move all initialization from run in >>>>> constructor and make most of variable 'final' it helps to ensure >>>>> that they are initialized. >>>>> ? 297???? public int run(final String args[], final PrintStream out) { >>>>> ? 298???????? ArgumentHandler argHandler = new ArgumentHandler(args); >>>>> ? 299 >>>>> ? 300???????? log = new Log(out, argHandler); >>>>> ? 301???????? eventTimeout = argHandler.getWaitTime() * 60 * 1000; >>>>> // milliseconds >>>>> ? 302???????? launchDebuggee(argHandler); >>>> >>>> Right comment in general, but I did not go with a constructor and >>>> final fields. >>>> Instead, I've just reorganized this a little bit. >>>> There is a little base to refactor to the constructor because the >>>> field "log" needs to be static and timeout can be local. >>>> >>>> >>>>> 8. Pair looks inconsistent. start saves handler as class field >>>>> while join use as parameter. >>>>> 305???????????? startEventHandler(); >>>>> 330???????????? joinEventHandler(eventHandler); >>>>> >>>>> I think that something like >>>>> EventHandler eventHandler = startEventHandler(); >>>>> joinEventHandler(eventHandler); >>>>> looks better and restrict usage of eventHandler. You also migt move >>>>> methods startEventHandler into EventHandler itself. >>>> >>>> Good suggestion - fixed. Moved both methods to the EventHandler class. >>>> >>>>> >>>>> 9. I suggest to make setHCRefType private and rename getHCRefType >>>>> to something like receiveHCRefType. To make more clear that it is >>>>> not a simple getter, but method which wait for event. >>>>> ? 361???????? // Save hidden class ReferenceType when its >>>>> ClassPrepare event is received. >>>>> ? 362???????? synchronized void setHCRefType(ReferenceType type) { >>>>> ? 363???????????? hcRefType = type; >>>>> ? 364???????????? notifyAll(); >>>>> ? 365???????? } >>>>> ? 366 >>>>> ? 367???????? // This method is used by the debugger main thread to >>>>> wait and get >>>>> ? 368???????? // the hidden class reference type from its >>>>> ClassPrepare event. >>>>> ? 369???????? // The readyCmdSync with the debuggeee is not enough >>>>> because a >>>>> ? 370???????? // ClassPrepare event sent over JDWP protocol has >>>>> some delay. >>>>> ? 371???????? // A wait/notify sync is to ensure the debugger gets >>>>> non-null value. >>>>> ? 372???????? synchronized ReferenceType getHCRefType() { >>>>> ? 373???????????? try { >>>>> ? 374???????????????? while (hcRefType == null) { >>>>> ? 375???????????????????? wait(); >>>>> ? 376???????????????? } >>>>> ? 377???????????? } catch (InterruptedException ie) { >>>>> ? 378???????????????? throw new Failure("Unexpected >>>>> InterruptedException in waiting for HC prepare: " + ie); >>>>> ? 379???????????? } >>>>> ? 380???????????? return hcRefType; >>>>> ? 381???????? } >>>> >>>> Good suggestion - fixed. I've replaced getHCRefType with >>>> waitGetHCRefType. >>>> Also, I've removed all uses of Failure and InterruptedException >>>> catches and specified a couple of methods to throw >>>> InterruptedException. >>>> >>>>> >>>>> 10. We don't run tests with -ea/esa so assertions usually disabled. >>>>> Use Assertions from test lib instead. The comment 1) is >>>>> recommendation only but 'assert' is just ignored. >>>>> ? 436???????????? assert name.indexOf("HiddenClass") > 0 && >>>>> name.indexOf("/0x") > 0; >>>> >>>> Thanks - fixed. >>>> >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001a.java.html >>>>> >>>>> >>>>> >>>>> 11. Check if jdk.test.lib.classloader.ClassLoadUtils. >>>>> getClassPath(String className) works for you instead of >>>>> ?? 70???? private static String getClassPath(Class klass) { >>>>> >>>>> 12. You could use try(log = new PrintStream("Debuggee.log")) {} here: >>>>> ?? 82???????? log = new PrintStream("Debuggee.log"); >>>>> .. >>>>> ?? 86???????? try { >>>>> .. >>>>> ? ?90???????? } >>>>> ?? 91???????? log.close(); >>>> >>>> Good idea, but unfortunately it does not work as the field needs to >>>> be static. >>>> >>>> >>>>> 13. It is better to throw RuntimeException and don't add throws >>>>> Exception in all methods. >>>>> 95???? private void syncWithDebugger(IOPipe pipe) throws Exception { >>>> >>>> Good suggestion - fixed. >>>> >>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent/classUnloadEvent001a.java.html >>>>> >>>>> >>>>> You could use single if for this. >>>>> ? 122???????? if (command == null) { >>>>> ? 123???????????? throw new Exception("Failed: pipe.readln() >>>>> returned null instead of COMMAND_QUIT"); >>>>> ? 124???????? } else if >>>>> (!command.equals(classUnloadEvent001.COMMAND_QUIT)) { >>>>> ? 125???????????? throw new Exception("Failed COMMAND_QUIT sync >>>>> with debugger, got unknown command: " + command); >>>>> ? 126???????? } >>>> >>>> I wanted a separate error message for (command == null) as it was >>>> related to OOME on the debuggee side. >>>> But it is not important anymore after the WT.fullGC() is used. >>>> Fixed. >>>> >>>>> 14. Setting to null is not required to collect objects here. >>>>> 151???????? hcObj = null; >>>>> 152???????? hc = null; >>>> >>>> It is better to keep these to be sure the hidden class can be unloaded. >>>> I had to create one mode hidden class to get a ClassUnload event. >>>> There is a comment in the test debuggee explaining it. >>>> >>>> >>>>> Probably I didn't catch all issues, but let discuss this list first. >>>> >>>> Okay. >>>> >>>> Thanks! >>>> Serguei >>>> >>>>> Leonid >>>>> >>>>> On 4/23/20 9:01 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review a fix for the sub-task: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8241807 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/ >>>>>> >>>>>> >>>>>> >>>>>> Summary; >>>>>> ? This sub-task is to cover any hidden class related remaining >>>>>> issues in the JDI and JDWP implementation. >>>>>> ? In fact, no more issues were discovered with this extra test >>>>>> coverage. >>>>>> ? So, this update includes only two new nsk jdi tests: >>>>>> || >>>>>> test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent >>>>>> || test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent >>>>>> >>>>>> ? These tests are to provide a test coverage? which was impossible >>>>>> to provide with the jdb testing framework. >>>>>> ? It includes ClassPrepare, Breakpoint and ModificationWatchpoint >>>>>> events with class filters. >>>>>> >>>>>> Testing: >>>>>> ? The mach5 job is in progress: >>>>>> https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jdi-event-tests-20200424-0350-10464032 >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >> > From serguei.spitsyn at oracle.com Wed Apr 29 20:53:52 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Apr 2020 13:53:52 -0700 Subject: RFR (L): 8241807: JDWP needs update for hidden classes In-Reply-To: References: <1726a6db-9012-e2b6-4e71-6658e493c4bd@oracle.com> <72cf8c8a-0aca-a9f3-fbd9-85882efc33f2@oracle.com> Message-ID: Thank you, Alex! Serguei On 4/29/20 12:21, Alex Menkov wrote: > LGTM > > --alex > > On 04/28/2020 18:31, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> The updated webrev version is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.6/ >> >> I'll push it if you have no objections. >> >> Thanks, >> Serguei >> >> >> >> On 4/28/20 18:03, serguei.spitsyn at oracle.com wrote: >>> Hi Alex, >>> >>> Thank you a lot for reviewing this. >>> >>> >>> On 4/28/20 17:35, Alex Menkov wrote: >>>> Hi Serguei, >>>> >>>> Looks good in general. >>>> couple minor notes: >>>> >>>> DebuggerBase.java >>>> >>>> - vm, debuggee, pipe and erManager fields and getDebuggee(), vm() >>>> methods don't need to be static; >>> >>> Thank you for the suggestion. >>> >>> The erManager and pipe are not static. >>> It feels like you need to refresh the webrev pages as I've updated >>> the webrev in place a couple of times while waited for review. >>> >>> The vm() method is used in the EventHandler class which does not >>> have a reference to the DebuggerBase object. >>> It is why the vm() needs to be static. >>> The same is true for 4 other methods: getReferenceType(), >>> findField(), findMethod() and invokeStaticMethod(). >>> I was also thinking on how to get rid of this staic-ness and decided >>> to leave it alone. >>> >>> The getDebuggee() method is not used yet. >>> I've removed it. It is not a problem to add it back in case it is >>> needed. >>> >>>> >>>> - replace all "imultiple" with "multiple". >>> >>> Nice catch - fixed. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> --alex >>>> >>>> >>>> On 04/27/2020 18:34, serguei.spitsyn at oracle.com wrote: >>>>> Hi Leonid, >>>>> >>>>> Updated webrev version with the suggested refactoring is: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.5/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Please, see my comments below. >>>>> >>>>> On 4/24/20 13:20, Leonid Mesnik wrote: >>>>>> >>>>>> Hi >>>>>> >>>>>> I have several comments about coding and desing. These tests >>>>>> might be used as examples for new JDI tests based on this >>>>>> framework so I think it would be better to polish them. >>>>>> >>>>> >>>>> Yes, as we agreed it'd be nice to create good examples, a base for >>>>> a future test development in the JDI area. >>>>> I also wanted to polish these tests as much as possible, so thanks >>>>> for helping with it. >>>>> These are good suggestions from you below. >>>>> One problem is that these tests will differ in style from the rest >>>>> of the NSK JDI tests but it has to be okay. >>>>> >>>>> >>>>>> General comment: >>>>>> >>>>>> 1. You often check results (not null, exactly one result). >>>>>> >>>>>> It makes sense to use jdk.test.lib.Asserts for such verification. >>>>>> Just to reduce number of code and fail with standard exceptions. >>>>>> >>>>> >>>>> Good suggestion - fixed now. >>>>> >>>>>> 2. Wildcard imports like 'import com.sun.jdi.*;' are not >>>>>> recommended. >>>>>> >>>>> >>>>> Good suggestion - fixed. >>>>> The list of imports became big but I see no problem with that. >>>>> >>>>>> 3. I recommend to catch Throwable instead of Exception especially >>>>>> in non-main threads. Just to ensure that nothing is missed. >>>>>> >>>>> >>>>> God suggestion - fixed, at least, in places where it makes sense >>>>> to do. >>>>> >>>>>> 4. nsk.share.Failure is subclass of RuntimeException so you don't >>>>>> need to add it to throws. Now sometimes it is added, sometimes >>>>>> not. It looks inconsistent. >>>>>> >>>>> >>>>> Good suggestion - fixed. >>>>> In fact, I did not like the use of Failure as it creates this >>>>> inconsistency, so I tried to get rid of it. >>>>> >>>>>> 5. There are lot of code duplication in debugger and debugge >>>>>> classes. Does it make a sense to merge it into base classes? >>>>>> >>>>> >>>>> I was thinking about this too but was reluctant to do so, as there >>>>> are just two tests. >>>>> But it has to be beneficial to move shared code to the JDI testing >>>>> framework. >>>>> I've just made some initial preparation by separating common parts >>>>> DebuggeeBase and DebuggerBase. >>>>> Also, it seems to be natural to move the HiddenClass and >>>>> EventHandler classes to their own files. >>>>> Then I've decided to combine both tests into one. >>>>> All refactoring still makes sense to have. >>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001.java.html >>>>>> >>>>>> >>>>>> 6. The getField can't return null, it verifies result. So check >>>>>> in line 191-193 is not needed. >>>>>> >>>>>> ? 190???????? Field field = getField(hcRefType, "hcField"); >>>>>> ??191???????? if (field == null) { >>>>>> ? 192???????????? throw new Failure("TEST FAILED: cannot enable >>>>>> ModificationWhatchpointRequest: hcField not found"); >>>>>> ? 193???????? } >>>>> >>>>> Good catch - fixed. >>>>> >>>>>> >>>>>> 7. I would recommend to move all initialization from run in >>>>>> constructor and make most of variable 'final' it helps to ensure >>>>>> that they are initialized. >>>>>> ? 297???? public int run(final String args[], final PrintStream >>>>>> out) { >>>>>> ? 298???????? ArgumentHandler argHandler = new >>>>>> ArgumentHandler(args); >>>>>> ? 299 >>>>>> ? 300???????? log = new Log(out, argHandler); >>>>>> ? 301???????? eventTimeout = argHandler.getWaitTime() * 60 * >>>>>> 1000; // milliseconds >>>>>> ? 302???????? launchDebuggee(argHandler); >>>>> >>>>> Right comment in general, but I did not go with a constructor and >>>>> final fields. >>>>> Instead, I've just reorganized this a little bit. >>>>> There is a little base to refactor to the constructor because the >>>>> field "log" needs to be static and timeout can be local. >>>>> >>>>> >>>>>> 8. Pair looks inconsistent. start saves handler as class field >>>>>> while join use as parameter. >>>>>> 305???????????? startEventHandler(); >>>>>> 330???????????? joinEventHandler(eventHandler); >>>>>> >>>>>> I think that something like >>>>>> EventHandler eventHandler = startEventHandler(); >>>>>> joinEventHandler(eventHandler); >>>>>> looks better and restrict usage of eventHandler. You also migt >>>>>> move methods startEventHandler into EventHandler itself. >>>>> >>>>> Good suggestion - fixed. Moved both methods to the EventHandler >>>>> class. >>>>> >>>>>> >>>>>> 9. I suggest to make setHCRefType private and rename getHCRefType >>>>>> to something like receiveHCRefType. To make more clear that it is >>>>>> not a simple getter, but method which wait for event. >>>>>> ? 361???????? // Save hidden class ReferenceType when its >>>>>> ClassPrepare event is received. >>>>>> ? 362???????? synchronized void setHCRefType(ReferenceType type) { >>>>>> ? 363???????????? hcRefType = type; >>>>>> ? 364???????????? notifyAll(); >>>>>> ? 365???????? } >>>>>> ? 366 >>>>>> ? 367???????? // This method is used by the debugger main thread >>>>>> to wait and get >>>>>> ? 368???????? // the hidden class reference type from its >>>>>> ClassPrepare event. >>>>>> ? 369???????? // The readyCmdSync with the debuggeee is not >>>>>> enough because a >>>>>> ? 370???????? // ClassPrepare event sent over JDWP protocol has >>>>>> some delay. >>>>>> ? 371???????? // A wait/notify sync is to ensure the debugger >>>>>> gets non-null value. >>>>>> ? 372???????? synchronized ReferenceType getHCRefType() { >>>>>> ? 373???????????? try { >>>>>> ? 374???????????????? while (hcRefType == null) { >>>>>> ? 375???????????????????? wait(); >>>>>> ? 376???????????????? } >>>>>> ? 377???????????? } catch (InterruptedException ie) { >>>>>> ? 378???????????????? throw new Failure("Unexpected >>>>>> InterruptedException in waiting for HC prepare: " + ie); >>>>>> ? 379???????????? } >>>>>> ? 380???????????? return hcRefType; >>>>>> ? 381???????? } >>>>> >>>>> Good suggestion - fixed. I've replaced getHCRefType with >>>>> waitGetHCRefType. >>>>> Also, I've removed all uses of Failure and InterruptedException >>>>> catches and specified a couple of methods to throw >>>>> InterruptedException. >>>>> >>>>>> >>>>>> 10. We don't run tests with -ea/esa so assertions usually >>>>>> disabled. Use Assertions from test lib instead. The comment 1) is >>>>>> recommendation only but 'assert' is just ignored. >>>>>> ? 436???????????? assert name.indexOf("HiddenClass") > 0 && >>>>>> name.indexOf("/0x") > 0; >>>>> >>>>> Thanks - fixed. >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent/classPrepEvent001a.java.html >>>>>> >>>>>> >>>>>> >>>>>> 11. Check if jdk.test.lib.classloader.ClassLoadUtils. >>>>>> getClassPath(String className) works for you instead of >>>>>> ?? 70???? private static String getClassPath(Class klass) { >>>>>> >>>>>> 12. You could use try(log = new PrintStream("Debuggee.log")) {} >>>>>> here: >>>>>> ?? 82???????? log = new PrintStream("Debuggee.log"); >>>>>> .. >>>>>> ?? 86???????? try { >>>>>> .. >>>>>> ? ?90???????? } >>>>>> ?? 91???????? log.close(); >>>>> >>>>> Good idea, but unfortunately it does not work as the field needs >>>>> to be static. >>>>> >>>>> >>>>>> 13. It is better to throw RuntimeException and don't add throws >>>>>> Exception in all methods. >>>>>> 95???? private void syncWithDebugger(IOPipe pipe) throws Exception { >>>>> >>>>> Good suggestion - fixed. >>>>> >>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent/classUnloadEvent001a.java.html >>>>>> >>>>>> >>>>>> You could use single if for this. >>>>>> ? 122???????? if (command == null) { >>>>>> ? 123???????????? throw new Exception("Failed: pipe.readln() >>>>>> returned null instead of COMMAND_QUIT"); >>>>>> ? 124???????? } else if >>>>>> (!command.equals(classUnloadEvent001.COMMAND_QUIT)) { >>>>>> ? 125???????????? throw new Exception("Failed COMMAND_QUIT sync >>>>>> with debugger, got unknown command: " + command); >>>>>> ? 126???????? } >>>>> >>>>> I wanted a separate error message for (command == null) as it was >>>>> related to OOME on the debuggee side. >>>>> But it is not important anymore after the WT.fullGC() is used. >>>>> Fixed. >>>>> >>>>>> 14. Setting to null is not required to collect objects here. >>>>>> 151???????? hcObj = null; >>>>>> 152???????? hc = null; >>>>> >>>>> It is better to keep these to be sure the hidden class can be >>>>> unloaded. >>>>> I had to create one mode hidden class to get a ClassUnload event. >>>>> There is a comment in the test debuggee explaining it. >>>>> >>>>> >>>>>> Probably I didn't catch all issues, but let discuss this list first. >>>>> >>>>> Okay. >>>>> >>>>> Thanks! >>>>> Serguei >>>>> >>>>>> Leonid >>>>>> >>>>>> On 4/23/20 9:01 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review a fix for the sub-task: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8241807 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-events.4/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary; >>>>>>> ? This sub-task is to cover any hidden class related remaining >>>>>>> issues in the JDI and JDWP implementation. >>>>>>> ? In fact, no more issues were discovered with this extra test >>>>>>> coverage. >>>>>>> ? So, this update includes only two new nsk jdi tests: >>>>>>> || >>>>>>> test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassPrepareEvent >>>>>>> || >>>>>>> test/hotspot/jtreg/vmTestbase/nsk/jdi/HiddenClass/ClassUnloadEvent >>>>>>> >>>>>>> ? These tests are to provide a test coverage? which was >>>>>>> impossible to provide with the jdb testing framework. >>>>>>> ? It includes ClassPrepare, Breakpoint and >>>>>>> ModificationWatchpoint events with class filters. >>>>>>> >>>>>>> Testing: >>>>>>> ? The mach5 job is in progress: >>>>>>> https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jdi-event-tests-20200424-0350-10464032 >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>> >>> >> From daniel.daugherty at oracle.com Wed Apr 29 22:34:18 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 29 Apr 2020 18:34:18 -0400 Subject: RFR(T) JDK-8214797: TestJmapCoreMetaspace.java timed out In-Reply-To: <298195da-970f-f069-5020-fb2f3cc337be@oracle.com> References: <298195da-970f-f069-5020-fb2f3cc337be@oracle.com> Message-ID: <286a3dd8-b250-7075-9e17-08dd552327a1@oracle.com> Thumbs up. And I agree that this is a trivial change. Dan On 4/28/20 4:57 PM, Chris Plummer wrote: > Hello, > > Please review the following trivial change: > > diff --git > a/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java > b/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java > --- a/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java > +++ b/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -26,5 +26,5 @@ > ? * @summary Test verifies that jhsdb jmap could generate heap dump > from core when metspace is full > ? * @requires vm.hasSA > ? * @library /test/lib > - * @run driver/timeout=240 TestJmapCore run metaspace > + * @run driver/timeout=480 TestJmapCore run metaspace > ? */ > > Sometimes on our macs a core dump takes much longer than usual. The > usual time is not much different than our other hosts, typically > taking 3-5 minutes. However some times it takes much longer. We've > seen them take up to 27 minutes. Once it approaches 18 minutes, that's > when you see test timeouts. Doubling the timeout gives us 32 minutes, > which would at least have prevented any of the timeouts we've seen so > far. > > BTW, limiting the timeout does not seem to limit how long the test > takes when one of these core dumps takes a long time. The test will > not complete (and then timeout) until the core dump is done. So this > change is not impacting how much time we spend on the test if we > encounter an even longer core dump that results in a timeout. > > thanks, > > Chris > From leonid.mesnik at oracle.com Wed Apr 29 23:45:58 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Wed, 29 Apr 2020 16:45:58 -0700 Subject: RFR: 8244133: Refactor nsk/jdi tests to reduce code duplication in settingBreakpoint communication Message-ID: <53C1DDD1-5FB7-47E8-9DE3-1DA0DE84579B@oracle.com> Hi Could you please review following fix which remove code duplication by moving methods BreakpointRequest settingBreakpoint, getEventSet, breakpointForCommunication and log1,2,3 in base class. The fix is huge but pretty straight forward, I tried to keep changes as small as possible so most tests just changed to extends JDIBase and corresponding methods and fields were deleted. Some tests used slightly different 'breakpointForCommunication()' implementation so they override it now. Some tests contain change like this: - eventRequest1 = eventRManager.createBreakpointRequest(location); + eventRequest1 = eventRManager.createBreakpointRequest(breakpLocation); it is because they had 'location' and not 'breakpLocation' which is set by settingBreakpoint(...). So just merged location and breakpLocation. All tests passed, so the main goal is to ensure that changes don't introduce false positive results ignoring exit codes and statuses. I quickly verified that updated files don't contain declarations of variable like PASSED, testExitCode and other. The JDIBase and all tests could be improved, also there are still a lot of tests which could use it as a base as well as other base classes for idi debuggers. However I want to keep this fix as simple as possible. werbev: http://cr.openjdk.java.net/~lmesnik/8244133/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8244133 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Apr 30 04:01:33 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 29 Apr 2020 21:01:33 -0700 Subject: RFR(T) JDK-8214797: TestJmapCoreMetaspace.java timed out In-Reply-To: <286a3dd8-b250-7075-9e17-08dd552327a1@oracle.com> References: <298195da-970f-f069-5020-fb2f3cc337be@oracle.com> <286a3dd8-b250-7075-9e17-08dd552327a1@oracle.com> Message-ID: <037e103e-6759-99c7-8294-050ef3a55ec4@oracle.com> Thanks Dan! On 4/29/20 3:34 PM, Daniel D. Daugherty wrote: > Thumbs up. And I agree that this is a trivial change. > > Dan > > > On 4/28/20 4:57 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following trivial change: >> >> diff --git >> a/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java >> b/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java >> --- a/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java >> +++ b/test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2018, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All >> rights reserved. >> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ? * >> ? * This code is free software; you can redistribute it and/or modify it >> @@ -26,5 +26,5 @@ >> ? * @summary Test verifies that jhsdb jmap could generate heap dump >> from core when metspace is full >> ? * @requires vm.hasSA >> ? * @library /test/lib >> - * @run driver/timeout=240 TestJmapCore run metaspace >> + * @run driver/timeout=480 TestJmapCore run metaspace >> ? */ >> >> Sometimes on our macs a core dump takes much longer than usual. The >> usual time is not much different than our other hosts, typically >> taking 3-5 minutes. However some times it takes much longer. We've >> seen them take up to 27 minutes. Once it approaches 18 minutes, >> that's when you see test timeouts. Doubling the timeout gives us 32 >> minutes, which would at least have prevented any of the timeouts >> we've seen so far. >> >> BTW, limiting the timeout does not seem to limit how long the test >> takes when one of these core dumps takes a long time. The test will >> not complete (and then timeout) until the core dump is done. So this >> change is not impacting how much time we spend on the test if we >> encounter an even longer core dump that results in a timeout. >> >> thanks, >> >> Chris >> > From serguei.spitsyn at oracle.com Thu Apr 30 04:53:26 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Apr 2020 21:53:26 -0700 Subject: RFR: 8244133: Refactor nsk/jdi tests to reduce code duplication in settingBreakpoint communication In-Reply-To: <53C1DDD1-5FB7-47E8-9DE3-1DA0DE84579B@oracle.com> References: <53C1DDD1-5FB7-47E8-9DE3-1DA0DE84579B@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Thu Apr 30 09:07:54 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 30 Apr 2020 11:07:54 +0200 Subject: RFR: 8244078: ProcessTools executeTestJvm and createJavaProcessBuilder have inconsistent handling of test.*.opts Message-ID: <44e3e1e7-7135-1892-12d3-cbf3707cfce0@oracle.com> Hi all, Please review this patch to make it less likely that we accidentally add or fail to add test.java.opts and test.vm.opts to our spawned test JVMs. https://cr.openjdk.java.net/~stefank/8244078/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8244078 ProcessTools.createJavaProcessBuilder(cmd) creates a ProcessBuilder *without* test.java.opts and test.vm.opts. There is a (addTestVmAndJavaOptions, cmd) overload that allows the caller to opt-in to the addition of these flags. The created ProcessBuilder is then used to start the JVM, and almost always fed into an OutputAnalyzer. There's another function executeTestJvm, that both creates a ProcessBuilder and then feeds it into an OutputAnalyzer (plus a bit more). This function uses createJavaProcessBuilder(true, cmd), and thereby adds the test.java.opts and test.vm.opts flags. This means that one has to know about this difference when reading code using createJavaProcessBuilder(cmd) and executeTestJvm(cmd), and when creating (copying) code using these functions. It has been suggested that createJavaProcessBuilder is intended to be a lower-level, building block API and that it's not confusing that they have different behavior. I don't really agree, but I'm buying into the notion of lower-level vs higher-level APIs here. So, my proposal is to remove the addTestVmAndJavaOptions feature from createJavaProcessBuilder, and instead create a new function called createTestJvm that adds test.java.opts and test.vm.opts. The name is intentionally similar to executeTestJvm, and in fact, the executeTestJvm implementation will use createTestJvm: public static OutputAnalyzer executeTestJvm(String... cmds) throws Exception { - ProcessBuilder pb = createJavaProcessBuilder(true, cmds); + ProcessBuilder pb = createTestJvm(cmds); return executeProcess(pb); } The rest of the patch is mainly: - leaving createJavaProcessBuilder(cmd) as is - replacing createJavaProcessBuilder(false, cmd) with createJavaProcessBuilder(cmd) - replacing createJavaProcessBuilder(true, cmd) with createTestJvm(cmd) There was one odd thing in jdi that requires extra scrutiny: https://cr.openjdk.java.net/~stefank/8244078/webrev.01/test/jdk/com/sun/jdi/lib/jdb/Debuggee.java.udiff.html I've run this through tier1-3, and are currently running this through higher tiers. Thanks, StefanK From Alan.Bateman at oracle.com Thu Apr 30 09:24:44 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Apr 2020 10:24:44 +0100 Subject: RFR: 8244078: ProcessTools executeTestJvm and createJavaProcessBuilder have inconsistent handling of test.*.opts In-Reply-To: <44e3e1e7-7135-1892-12d3-cbf3707cfce0@oracle.com> References: <44e3e1e7-7135-1892-12d3-cbf3707cfce0@oracle.com> Message-ID: On 30/04/2020 10:07, Stefan Karlsson wrote: > Hi all, > > Please review this patch to make it less likely that we accidentally > add or fail to add test.java.opts and test.vm.opts to our spawned test > JVMs. > > https://cr.openjdk.java.net/~stefank/8244078/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8244078 We tried a few years ago to get the tests in the libraries areas moved to using the xxxJava variants of these methods to make it clear that it exec'ing the java launcher of the JDK under test. Methods such as executeTestJvm were deprecated as the naming didn't make it clear that it exec's the java launcher. Looks like some of this has been lost with the combining of the test infrastructure. So while not directly to this webrev, I think we need to go back to the naming issue at some point and avoid having two sets of methods that do the same thing. -Alan From david.holmes at oracle.com Thu Apr 30 09:59:48 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Apr 2020 19:59:48 +1000 Subject: RFR: 8244078: ProcessTools executeTestJvm and createJavaProcessBuilder have inconsistent handling of test.*.opts In-Reply-To: <44e3e1e7-7135-1892-12d3-cbf3707cfce0@oracle.com> References: <44e3e1e7-7135-1892-12d3-cbf3707cfce0@oracle.com> Message-ID: Hi Stefan, On 30/04/2020 7:07 pm, Stefan Karlsson wrote: > Hi all, > > Please review this patch to make it less likely that we accidentally add > or fail to add test.java.opts and test.vm.opts to our spawned test JVMs. > > https://cr.openjdk.java.net/~stefank/8244078/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8244078 > > ProcessTools.createJavaProcessBuilder(cmd) creates a ProcessBuilder > *without* test.java.opts and test.vm.opts. There is a > (addTestVmAndJavaOptions, cmd) overload that allows the caller to opt-in > to the addition of these flags. The created ProcessBuilder is then used > to start the JVM, and almost always fed into an OutputAnalyzer. > > There's another function executeTestJvm, that both creates a > ProcessBuilder and then feeds it into an OutputAnalyzer (plus a bit > more). This function uses createJavaProcessBuilder(true, cmd), and > thereby adds the test.java.opts and test.vm.opts flags. > > This means that one has to know about this difference when reading code > using createJavaProcessBuilder(cmd) and executeTestJvm(cmd), and when > creating (copying) code using these functions. > > It has been suggested that createJavaProcessBuilder is intended to be a > lower-level, building block API and that it's not confusing that they > have different behavior. I don't really agree, but I'm buying into the > notion of lower-level vs higher-level APIs here. So, my proposal is to > remove the addTestVmAndJavaOptions feature from > createJavaProcessBuilder, and instead create a new function called > createTestJvm that adds test.java.opts and test.vm.opts. The name is > intentionally similar to executeTestJvm, and in fact, the executeTestJvm > implementation will use createTestJvm: > > ???? public static OutputAnalyzer executeTestJvm(String... cmds) throws > Exception { > - ProcessBuilder pb = createJavaProcessBuilder(true, cmds); > + ProcessBuilder pb = createTestJvm(cmds); > ???????? return executeProcess(pb); > ???? } > > The rest of the patch is mainly: > - leaving createJavaProcessBuilder(cmd) as is > - replacing createJavaProcessBuilder(false, cmd) with > createJavaProcessBuilder(cmd) > - replacing createJavaProcessBuilder(true, cmd) with createTestJvm(cmd) This all looks good to me. I think this high/low API makes things much clearer. An observation from compiler/runtime/cr8015436/Driver8015436.java - can: oa = ProcessTools.executeProcess(ProcessTools.createTestJvm(...)); be replaced with oa = executeTestJvm(...); ? --- test/hotspot/jtreg/gc/arguments/GCArguments.java Isn't the String[] <-> List conversion already handled in ProcessTools? This looks like an area where GC added its own helper utilities early on and they aren't really needed any more. Future RFE? --- test/hotspot/jtreg/gc/g1/mixedgc/TestLogging.java test/hotspot/jtreg/gc/nvdimm/* Just observation - these tests also use a code pattern that looks like it could use executeTestJvm instead. --- test/lib/jdk/test/lib/process/ProcessTools.java This looks a bit odd: /** * @see #executeTestJvm(String...) * @param cmds User specified arguments. * @return The output from the process. */ public static OutputAnalyzer executeTestJava(String... cmds) throws Exception { return executeTestJvm(cmds); } I assume this exists because this was the name used in the JDK test library originally and many (most?) of the JDK tests call it rather than executeTestJvm. There are a couple of hotspot callers that should probably be converted over: ./jtreg/compiler/jvmci/errors/TestInvalidTieredStopAtLevel.java ./jtreg/compiler/jvmci/TestValidateModules.java otherwise another future RFE to switch over to single API. > There was one odd thing in jdi that requires extra scrutiny: > https://cr.openjdk.java.net/~stefank/8244078/webrev.01/test/jdk/com/sun/jdi/lib/jdb/Debuggee.java.udiff.html As there are no callers of the addTestVmAndJavaOptions(boolean) API these changes seem fine. I can understand why the ability to select whether or not to add the test harness args was made available, but it seems no test is concerned about using it, so it can go. Thanks, David ----- > > I've run this through tier1-3, and are currently running this through > higher tiers. > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Apr 30 10:08:37 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 30 Apr 2020 12:08:37 +0200 Subject: RFR: 8244078: ProcessTools executeTestJvm and createJavaProcessBuilder have inconsistent handling of test.*.opts In-Reply-To: References: <44e3e1e7-7135-1892-12d3-cbf3707cfce0@oracle.com> Message-ID: <06bc26af-d877-c1fa-c736-20eb0a76d1a5@oracle.com> On 2020-04-30 11:24, Alan Bateman wrote: > On 30/04/2020 10:07, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to make it less likely that we accidentally >> add or fail to add test.java.opts and test.vm.opts to our spawned >> test JVMs. >> >> https://cr.openjdk.java.net/~stefank/8244078/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8244078 > We tried a few years ago to get the tests in the libraries areas moved > to using the xxxJava variants of these methods to make it clear that > it exec'ing the java launcher of the JDK under test. Methods such as > executeTestJvm were deprecated as the naming didn't make it clear that > it exec's the java launcher. Looks like some of this has been lost > with the combining of the test infrastructure. So while not directly > to this webrev, I think we need to go back to the naming issue at some > point and avoid having two sets of methods that do the same thing. Are you specifically referring to executeTestJvm vs executeTestJava? We could take a step back and look at all these functions and try to find good names and/or default values. If we're going to clean this up, I think we need to figure out good and, preferably, concise naming for all of these: - create test java launcher with test.*.opts - create test java launcher without test.*.opts - execute test java launcher with test.*opts - execute test java launcher without test.*.opts Do you want me to hold off on this patch until we've resolved this? StefanK > > -Alan From stefan.karlsson at oracle.com Thu Apr 30 10:22:19 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 30 Apr 2020 12:22:19 +0200 Subject: RFR: 8244078: ProcessTools executeTestJvm and createJavaProcessBuilder have inconsistent handling of test.*.opts In-Reply-To: References: <44e3e1e7-7135-1892-12d3-cbf3707cfce0@oracle.com> Message-ID: <43cc7b8d-7038-e77e-553a-22c76ca80b78@oracle.com> Hi David, On 2020-04-30 11:59, David Holmes wrote: > Hi Stefan, > > On 30/04/2020 7:07 pm, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to make it less likely that we accidentally >> add or fail to add test.java.opts and test.vm.opts to our spawned >> test JVMs. >> >> https://cr.openjdk.java.net/~stefank/8244078/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8244078 >> >> ProcessTools.createJavaProcessBuilder(cmd) creates a ProcessBuilder >> *without* test.java.opts and test.vm.opts. There is a >> (addTestVmAndJavaOptions, cmd) overload that allows the caller to >> opt-in to the addition of these flags. The created ProcessBuilder is >> then used to start the JVM, and almost always fed into an >> OutputAnalyzer. >> >> There's another function executeTestJvm, that both creates a >> ProcessBuilder and then feeds it into an OutputAnalyzer (plus a bit >> more). This function uses createJavaProcessBuilder(true, cmd), and >> thereby adds the test.java.opts and test.vm.opts flags. >> >> This means that one has to know about this difference when reading >> code using createJavaProcessBuilder(cmd) and executeTestJvm(cmd), and >> when creating (copying) code using these functions. >> >> It has been suggested that createJavaProcessBuilder is intended to be >> a lower-level, building block API and that it's not confusing that >> they have different behavior. I don't really agree, but I'm buying >> into the notion of lower-level vs higher-level APIs here. So, my >> proposal is to remove the addTestVmAndJavaOptions feature from >> createJavaProcessBuilder, and instead create a new function called >> createTestJvm that adds test.java.opts and test.vm.opts. The name is >> intentionally similar to executeTestJvm, and in fact, the >> executeTestJvm implementation will use createTestJvm: >> >> ????? public static OutputAnalyzer executeTestJvm(String... cmds) >> throws Exception { >> - ProcessBuilder pb = createJavaProcessBuilder(true, cmds); >> + ProcessBuilder pb = createTestJvm(cmds); >> ????????? return executeProcess(pb); >> ????? } >> >> The rest of the patch is mainly: >> - leaving createJavaProcessBuilder(cmd) as is >> - replacing createJavaProcessBuilder(false, cmd) with >> createJavaProcessBuilder(cmd) >> - replacing createJavaProcessBuilder(true, cmd) with createTestJvm(cmd) > > This all looks good to me. I think this high/low API makes things much > clearer. > > An observation from compiler/runtime/cr8015436/Driver8015436.java - can: > > oa = ProcessTools.executeProcess(ProcessTools.createTestJvm(...)); > > be replaced with > > oa = executeTestJvm(...); > > ? Yes. Good point. > > --- > > test/hotspot/jtreg/gc/arguments/GCArguments.java > > Isn't the String[] <-> List conversion already handled in > ProcessTools? > > This looks like an area where GC added its own helper utilities early > on and they aren't really needed any more. Future RFE? I thought the same when I first looked at this, but there's a subtle withDefaults(...) call in there that filters out some of the passed in flags. However, it's weird because it doesn't filter the test.vm.opts and test.java.opts, only the flags that the tests explicitly passes in. I think we need to take a closer look at this, as a separate RFE. > > --- > > test/hotspot/jtreg/gc/g1/mixedgc/TestLogging.java > test/hotspot/jtreg/gc/nvdimm/* > > Just observation - these tests also use a code pattern that looks like > it could use executeTestJvm instead. Are you thinking about: ??? ProcessBuilder pb = ProcessTools.createTestJvm(flags); ??? OutputAnalyzer output = new OutputAnalyzer(pb.start()); Yes, my goal is to be able to replace those line with a one-liner. There is huge number of places were we have this pattern. However, note that executeTestJvm waits for the process to finish and dumps the output to files. new OutputAnalyzer(pb.start()) doesn't AFAICT. Either we think executeTestJvm is the right approach, or we have to create yet another function that performs the above code. > > --- > > test/lib/jdk/test/lib/process/ProcessTools.java > > This looks a bit odd: > > ?? /** > ???? * @see #executeTestJvm(String...) > ???? * @param cmds User specified arguments. > ???? * @return The output from the process. > ???? */ > ??? public static OutputAnalyzer executeTestJava(String... cmds) > throws Exception { > ??????? return executeTestJvm(cmds); > ??? } > > I assume this exists because this was the name used in the JDK test > library originally and many (most?) of the JDK tests call it rather > than executeTestJvm. There are a couple of hotspot callers that should > probably be converted over: > > ./jtreg/compiler/jvmci/errors/TestInvalidTieredStopAtLevel.java > ./jtreg/compiler/jvmci/TestValidateModules.java > > otherwise another future RFE to switch over to single API. I think this is what Alan mentioned in his mail. I thought the executeTestJava call was the deprecated one, but apparently it's the other way around. > >> There was one odd thing in jdi that requires extra scrutiny: >> https://cr.openjdk.java.net/~stefank/8244078/webrev.01/test/jdk/com/sun/jdi/lib/jdb/Debuggee.java.udiff.html > > > As there are no callers of the addTestVmAndJavaOptions(boolean) API > these changes seem fine. I can understand why the ability to select > whether or not to add the test harness args was made available, but it > seems no test is concerned about using it, so it can go. Thanks, StefanK > > > Thanks, > David > ----- > >> >> I've run this through tier1-3, and are currently running this through >> higher tiers. >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Thu Apr 30 10:26:52 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 30 Apr 2020 03:26:52 -0700 (PDT) Subject: RFR: 8244078: ProcessTools executeTestJvm and createJavaProcessBuilder have inconsistent handling of test.*.opts In-Reply-To: <43cc7b8d-7038-e77e-553a-22c76ca80b78@oracle.com> References: <44e3e1e7-7135-1892-12d3-cbf3707cfce0@oracle.com> <43cc7b8d-7038-e77e-553a-22c76ca80b78@oracle.com> Message-ID: On 2020-04-30 12:22, Stefan Karlsson wrote: > Hi David, > > On 2020-04-30 11:59, David Holmes wrote: ... >> >> --- >> >> test/hotspot/jtreg/gc/arguments/GCArguments.java >> >> Isn't the String[] <-> List conversion already handled in >> ProcessTools? >> >> This looks like an area where GC added its own helper utilities early >> on and they aren't really needed any more. Future RFE? > I thought the same when I first looked at this, but there's a subtle > withDefaults(...) call in there that filters out some of the passed in > flags. > > However, it's weird because it doesn't filter the test.vm.opts and > test.java.opts, only the flags that the tests explicitly passes in. I > think we need to take a closer look at this, as a separate RFE. I read the disableX part to quickly. This *adds* flags to turn off features. StefanK From Alan.Bateman at oracle.com Thu Apr 30 10:36:16 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Apr 2020 11:36:16 +0100 Subject: RFR: 8244078: ProcessTools executeTestJvm and createJavaProcessBuilder have inconsistent handling of test.*.opts In-Reply-To: <06bc26af-d877-c1fa-c736-20eb0a76d1a5@oracle.com> References: <44e3e1e7-7135-1892-12d3-cbf3707cfce0@oracle.com> <06bc26af-d877-c1fa-c736-20eb0a76d1a5@oracle.com> Message-ID: <43412b9f-331a-7097-d854-d5cc8196e5ea@oracle.com> On 30/04/2020 11:08, Stefan Karlsson wrote: > > Are you specifically referring to executeTestJvm vs executeTestJava? Yes, executeTestJvm was deprecated in the test/lib/testlibrary/jdk/testlibrary/ProcessTools.java but it seems to have come back, maybe when we move to a single repo. I only bring it up because there are a couple of tests in your webrev that are changed to use executeTestJvm when I expected they would use executeTestJava. > > We could take a step back and look at all these functions and try to > find good names and/or default values. If we're going to clean this > up, I think we need to figure out good and, preferably, concise naming > for all of these: > - create test java launcher with test.*.opts > - create test java launcher without test.*.opts > - execute test java launcher with test.*opts > - execute test java launcher without test.*.opts > > Do you want me to hold off on this patch until we've resolved this? I don't want to delay your work. I think we just need to create a few issues to do some cleanup and maybe remove the methods from ProcessTools that have misleading names. -Alan From igor.ignatyev at oracle.com Thu Apr 30 23:30:23 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 30 Apr 2020 16:30:23 -0700 (PDT) Subject: RFR(S/M) : 8243436 : use reproducible random in :vmTestbase_nsk_monitoring Message-ID: http://cr.openjdk.java.net/~iignatyev/8243436/webrev.00 > 305 lines changed: 76 ins; 11 del; 218 mod; Hi all, could you please review this patch? from JBS: > this subtask is to use j.t.l.Utils.getRandomInstance() as a random number generator, where applicable, in : vmTestbase_nsk_monitoring test group and marking the tests which make use of "randomness" with a proper k/w. testing: : vmTestbase_nsk_monitoring test group JBS: https://bugs.openjdk.java.net/browse/JDK-8243436 webrevs: - code changes: http://cr.openjdk.java.net/~iignatyev//8243436/webrev.00.code > 19 lines changed: 5 ins; 11 del; 3 mod; - adding k/w: http://cr.openjdk.java.net/~iignatyev//8243436/webrev.00.kw > 141 lines changed: 71 ins; 0 del; 70 mod; - full: http://cr.openjdk.java.net/~iignatyev//8243436/webrev.00 > 305 lines changed: 76 ins; 11 del; 218 mod; Thanks, -- Igor From igor.ignatyev at oracle.com Thu Apr 30 23:46:32 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 30 Apr 2020 16:46:32 -0700 Subject: RFR(S) : 8243435 : use reproducible random in :vmTestbase_nsk_jvmti Message-ID: http://cr.openjdk.java.net/~iignatyev/8243435/webrev.00 > 49 lines changed: 19 ins; 5 del; 25 mod; Hi all, could you please review this patch? from JBS: > this subtask is to use j.t.l.Utils.getRandomInstance() as a random number generator, where applicable, in : vmTestbase_nsk_jvmti test group and marking the tests which make use of "randomness" with a proper k/w. testing: : vmTestbase_nsk_jvmti test group JBS: https://bugs.openjdk.java.net/browse/JDK-8243435 webrevs: - code changes: http://cr.openjdk.java.net/~iignatyev//8243435/webrev.00.code > 7 lines changed: 1 ins; 5 del; 1 mod; - adding k/w: http://cr.openjdk.java.net/~iignatyev//8243435/webrev.00.kw > 18 lines changed: 18 ins; 0 del; 0 mod; - full: http://cr.openjdk.java.net/~iignatyev//8243435/webrev.00 > 49 lines changed: 19 ins; 5 del; 25 mod; Thanks, -- Igor From igor.ignatyev at oracle.com Thu Apr 30 23:52:06 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 30 Apr 2020 16:52:06 -0700 Subject: RFR(S) : 8243437 : use reproducible random in :vmTestbase_nsk_jdi Message-ID: <32CF125B-6481-48EA-873B-194537179776@oracle.com> http://cr.openjdk.java.net/~iignatyev/8243437/webrev.00 > 62 lines changed: 26 ins; 0 del; 36 mod; Hi all, could you please review this small patch? from JBS: > this subtask is to use j.t.l.Utils.getRandomInstance() as a random number generator, where applicable, in : vmTestbase_nsk_jdi test group and marking the tests which make use of "randomness" with a proper k/w. testing: : vmTestbase_nsk_jdi test group JBS: https://bugs.openjdk.java.net/browse/JDK-8243437 webrev: http://cr.openjdk.java.net/~iignatyev/8243437/webrev.00 (all code changes have already happened in 8242314 'use reproducible random in vmTestbase shared code', so just k/w and copyright years this time) Thanks, -- Igor