From sspitsyn at openjdk.java.net Thu Oct 1 00:22:03 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 1 Oct 2020 00:22:03 GMT Subject: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 21:28:19 GMT, Ziviani wrote: >> TestInstanceKlassSize was failing because, for PowerPC, the following code (instanceKlass.cpp) always compiles to >> `return false;` bool InstanceKlass::has_stored_fingerprint() const { >> #if INCLUDE_AOT >> return should_store_fingerprint() || is_shared(); >> #else >> return false; >> #endif >> } >> However, in `hasStoredFingerprint()@InstanceKlass.java` the condition `shouldStoreFingerprint() || isShared();` is >> always evaluated and may return true (_AFAIK isShared() returns true_). Such condition adds 8 bytes in the >> `getSize()@InstanceKlass.java` causing the failure in TestInstanceKlassSize: public long getSize() { // in number of >> bytes >> ... >> if (hasStoredFingerprint()) { >> size += 8; // uint64_t >> } >> return alignSize(size); >> } >> Considering these tests are failing for PowerPC only (_based on ProblemList.txt_), my solution checks if >> `hasStoredFingerprint()` is running on a PowerPC platform. I decided to go this way because there is no existing flag >> informing whether AOT is included or not and creating a new one just to handle the PowerPC case seems too much. This >> patch is an attempt to fix https://bugs.openjdk.java.net/browse/JDK-8230664 > > Ziviani has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes > the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last > revision: > 8230664: Fix TestInstanceKlassSize > > The code hasStoredFingerprint() at InstanceKlass.java is not considering > AOT disabled at compilation time, like has_stored_fingerprint() at > instanceKlass.cpp does. Such difference can cause TestInstanceKlassSize > failures because all objects will have an extra 8-bytes. LGTM ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/358 From sspitsyn at openjdk.java.net Thu Oct 1 00:27:56 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 1 Oct 2020 00:27:56 GMT Subject: RFR: 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 22:51:59 GMT, Leonid Mesnik wrote: > Test fails with -XX:-TieredCompilation because j.l.Object hasn't been used enough time to trigger compilation. The > default CompileThreshold value is good enough when tiered compilation is enabled (by default) but not for server-only > mode. So it is needed to reduce CompileThreshold to ensure that methods are compiled in any mode. Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/447 From vromero at openjdk.java.net Thu Oct 1 01:31:04 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 1 Oct 2020 01:31:04 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v9] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com> > Co-authored-by: Vicente Romero > Co-authored-by: Harold Seigel > Co-authored-by: Jonathan Gibbons > Co-authored-by: Brian Goetz > Co-authored-by: Maurizio Cimadamore > Co-authored-by: Joe Darcy > Co-authored-by: Chris Hegarty > Co-authored-by: Jan Lahoda Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: remove unnecessary jtreg tags from tests, remove othervm etc when applicable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/76e3d278..7501148d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=07-08 Stats: 102 lines in 54 files changed: 33 ins; 19 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Thu Oct 1 01:33:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 1 Oct 2020 01:33:58 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Wed, 30 Sep 2020 08:54:14 GMT, Chris Hegarty wrote: >> test/langtools/tools/javac/records/LocalStaticDeclarations.java line 33: >> >>> 31: * jdk.compiler/com.sun.tools.javac.util >>> 32: * @build combo.ComboTestHelper >>> 33: * @compile LocalStaticDeclarations.java >> >> This, and other, explicit at compile tags could be elided, no? The test source file will be implicitly compiled by the >> at run tag. I believe that the explicit at compile tag was added original so that the enable preview and source version >> options could be passed to javac - neither of which are needed any more. > > Does this test need an @run tag rather than an @compile tag ? ( the @run with implicitly compile the source file, > before running it ) @ChrisHegarty I have created commit [7501148](https://github.com/openjdk/jdk/pull/290/commits/7501148dd4c21847699a84d6dc5ef100d993b78d) to address this issue, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From eosterlund at openjdk.java.net Thu Oct 1 09:18:38 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 1 Oct 2020 09:18:38 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v9] In-Reply-To: References: Message-ID: <4lDALRmzwYmR7Fjl7vyUhbjpryVmVjh_lDKAwTp8Fwc=.511a9972-8ba7-4304-99ab-3c548ccc111b@github.com> > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Review: Kim CR 1 and exception handling fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/296/files - new: https://git.openjdk.java.net/jdk/pull/296/files/2ffbd764..83c40895 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=07-08 Stats: 82 lines in 9 files changed: 48 ins; 26 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From chegar at openjdk.java.net Thu Oct 1 09:32:03 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 1 Oct 2020 09:32:03 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v9] In-Reply-To: <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com> Message-ID: On Thu, 1 Oct 2020 01:31:04 GMT, Vicente Romero wrote: >> Co-authored-by: Vicente Romero >> Co-authored-by: Harold Seigel >> Co-authored-by: Jonathan Gibbons >> Co-authored-by: Brian Goetz >> Co-authored-by: Maurizio Cimadamore >> Co-authored-by: Joe Darcy >> Co-authored-by: Chris Hegarty >> Co-authored-by: Jan Lahoda > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > remove unnecessary jtreg tags from tests, remove othervm etc when applicable Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From eosterlund at openjdk.java.net Thu Oct 1 09:53:21 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 1 Oct 2020 09:53:21 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8] In-Reply-To: <4sawJHiIuc7oH5ETjrwJtJE3gkB1U2VBMVJdPmxJrg4=.e4e9b4d3-a118-4870-9b5b-f23b351093e2@github.com> References: <4sawJHiIuc7oH5ETjrwJtJE3gkB1U2VBMVJdPmxJrg4=.e4e9b4d3-a118-4870-9b5b-f23b351093e2@github.com> Message-ID: On Tue, 29 Sep 2020 16:09:48 GMT, Robbin Ehn wrote: >> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 12 commits: >> - Review: Move barrier detach >> - Review: Remove assert that has outstayed its welcome >> - Merge branch 'master' into 8253180_conc_stack_scanning >> - Review: Albert CR2 and defensive programming >> - Review: StefanK CR 3 >> - Review: Per CR 1 >> - Merge branch 'master' into 8253180_conc_stack_scanning >> - Review: Albert CR 1 >> - Review: SteafanK CR 2 >> - Merge branch 'master' into 8253180_conc_stack_scanning >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6bddeb70...2ffbd764 > > Marked as reviewed by rehn (Reviewer). > _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on > [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ > I've only looked at scattered pieces, but what I've looked at seemed to be > in good shape. Only a few minor comments. > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/frame.cpp > 456 // for(StackFrameStream fst(thread); !fst.is_done(); fst.next()) { > > Needs to be updated for the new constructor arguments. Just in general, the > class documentation seems to need some updating for this change. Fixed. > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/frame.cpp > 466 StackFrameStream(JavaThread *thread, bool update, bool process_frames); > > Something to consider is that bool parameters like that, especially when > there are multiple, are error prone. An alternative is distinct enums, which > likely also obviates the need for comments in calls. Coleen also had the same comment, and we agreed to file a follow-up RFE to clean that up. This also applies to all the existing parameters passed in. So I would still like to do that, but in a follow-up RFE. Said RFE will also make the parameter use in RegisterMap and vframeStream explicit. > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/thread.hpp > 956 void set_processed_thread(Thread *thread) { _processed_thread = thread; } > > I think this should assert that either _processed_thread or thread are NULL. > Or maybe the RememberProcessedThread constructor should be asserting that > _cur_thr->processed_thread() is NULL. Fixed. > ------------------------------------------------------------------------------ Thanks for the review Kim! ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Thu Oct 1 10:15:32 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 1 Oct 2020 10:15:32 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8] In-Reply-To: References: <4sawJHiIuc7oH5ETjrwJtJE3gkB1U2VBMVJdPmxJrg4=.e4e9b4d3-a118-4870-9b5b-f23b351093e2@github.com> Message-ID: On Thu, 1 Oct 2020 09:50:45 GMT, Erik ?sterlund wrote: >> Marked as reviewed by rehn (Reviewer). > >> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on >> [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ >> I've only looked at scattered pieces, but what I've looked at seemed to be >> in good shape. Only a few minor comments. >> >> ------------------------------------------------------------------------------ >> src/hotspot/share/runtime/frame.cpp >> 456 // for(StackFrameStream fst(thread); !fst.is_done(); fst.next()) { >> >> Needs to be updated for the new constructor arguments. Just in general, the >> class documentation seems to need some updating for this change. > > Fixed. > >> ------------------------------------------------------------------------------ >> src/hotspot/share/runtime/frame.cpp >> 466 StackFrameStream(JavaThread *thread, bool update, bool process_frames); >> >> Something to consider is that bool parameters like that, especially when >> there are multiple, are error prone. An alternative is distinct enums, which >> likely also obviates the need for comments in calls. > > Coleen also had the same comment, and we agreed to file a follow-up RFE to clean that up. This also applies to all the > existing parameters passed in. So I would still like to do that, but in a follow-up RFE. Said RFE will also make the > parameter use in RegisterMap and vframeStream explicit. >> ------------------------------------------------------------------------------ >> src/hotspot/share/runtime/thread.hpp >> 956 void set_processed_thread(Thread *thread) { _processed_thread = thread; } >> >> I think this should assert that either _processed_thread or thread are NULL. >> Or maybe the RememberProcessedThread constructor should be asserting that >> _cur_thr->processed_thread() is NULL. > > Fixed. > >> ------------------------------------------------------------------------------ > > Thanks for the review Kim! In my last PR update, I included a fix to an exception handling problem that I encountered after lots of stress testing that I have been running for a while now. I managed to catch the issue, get a reliable reproducer, and fix it. The root problem is that the hook I had placed in SharedRuntime::exception_handler_for_return_address has been ignored. The reason is that the stack is not walkable at this point. The hook then just ignores it. This had some unexpected consequences. After looking closer at this code, I found that if we did have a walkable stack when we call SharedRuntime::raw_exception_handler_for_return_address, that would have been the only hook we need at all for exception handling. It is always the common root point where we unwind into a caller frame due to an exception throwing into the caller, and we need to look up the rethrow handler of the caller. However, we are indeed not walkable here. To deal with this, I have rearranged the exceptino hooks a bit. First of all, I have deleted all before_unwind hooks for exception handling, because they should not be needed if the after_unwind hook is reliably called on the caller side instead. And those hooks do indeed need to be there, because we do not always have a point where we can call before_unwind (e.g. C1 unwind exception code, that just unwinds and looks up the rethrow handler via SharedRuntime::exception_handler_for_return_address). I have then traced all paths from SharedRuntime::raw_exception_handler_for_return_address into runtime rethrow handlers called, for each rethrow exception handler PC exposed in the function. They are: * OptoRuntime::rethrow_C when unwinding into C2 code * exception_handler_for_pc_helper via Runtime1::handle_exception_from_callee_id when unwinding into C1 code * JavaCallWrapper::~JavaCallWrapper when unwinding into a Java call stub * InterpreterRuntime::exception_handler_for_exception when unwinding into an interpreted method * Deoptimization::fetch_unroll_info (with exec_mode == Unpack_exception) when unwinding into a deoptimized nmethod Each rethrow handler returned has a corresponding comment saying which rethrow runtime rethrow handler it will end up in, once the stack has been walkable and we have transferred control into the caller. And all of those runtime hooks now have an after_unwind() hook. The good news is that now the responsibility for who calls the unwind hook for exception is clearer: it is never done by the callee, and always done by the caller, in its rethrow handler, at which point the stack is walkable. In order to avoid further issues where an unwind hook is ignored, I have changed them to assert that there is a last_Java_frame present. Previously I did not assert that, because there was shared code between runtime native transitions and the native wrapper, that called an unwind hook. This prevented the unwind hooks to assert this, as compiler threads would still perform native transitions, that just ignored the request. I moved the problematic hook for native up one level in the hierarchy to a path where it is only called by native wrappers (where we always have a last_Java_frame), so that I can finally assert that the unwind hooks always are called at points where we have a last_Java_frame. This makes me feel confident that I do not have another hook that is being accidentally ignored. However, the relationship for the various exception handling code executed in the caller, the callee, and between the two (before we are walkable) is rather complicated. So it would be good to have someone that knows the exception code very well have a look at this, to make sure I have not missed anything. I have rerun all testing and done a load of stress testing to sanity check this. The reproducer I eventually found that reproduced the issue with 100% success rate, was run many times with the new patch, and no longer reproduces any issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From kim.barrett at oracle.com Thu Oct 1 10:36:38 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 1 Oct 2020 06:36:38 -0400 Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8] In-Reply-To: References: <4sawJHiIuc7oH5ETjrwJtJE3gkB1U2VBMVJdPmxJrg4=.e4e9b4d3-a118-4870-9b5b-f23b351093e2@github.com> Message-ID: <9D9D71DC-1AB6-41BE-A515-C0510FA47EC0@oracle.com> > On Oct 1, 2020, at 5:53 AM, Erik ?sterlund wrote: > > >> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) onsrc/hotspot/share/runtime/frame.cpp >> 466 StackFrameStream(JavaThread *thread, bool update, bool process_frames); >> >> Something to consider is that bool parameters like that, especially when >> there are multiple, are error prone. An alternative is distinct enums, which >> likely also obviates the need for comments in calls. > > Coleen also had the same comment, and we agreed to file a follow-up RFE to clean that up. This also applies to all the > existing parameters passed in. So I would still like to do that, but in a follow-up RFE. Said RFE will also make the > parameter use in RegisterMap and vframeStream explicit. That?s fine with me. From mdoerr at openjdk.java.net Thu Oct 1 12:23:47 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 1 Oct 2020 12:23:47 GMT Subject: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2] In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 00:19:09 GMT, Serguei Spitsyn wrote: >> Ziviani has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains >> one commit: >> 8230664: Fix TestInstanceKlassSize >> >> The code hasStoredFingerprint() at InstanceKlass.java is not considering >> AOT disabled at compilation time, like has_stored_fingerprint() at >> instanceKlass.cpp does. Such difference can cause TestInstanceKlassSize >> failures because all objects will have an extra 8-bytes. > > LGTM I think this fix deserves a new JBS issue. It doesn't resolve the rounding problem described in JDK-8230664. It fixes an additiona issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From github.com+670087+jrziviani at openjdk.java.net Thu Oct 1 14:04:04 2020 From: github.com+670087+jrziviani at openjdk.java.net (Ziviani) Date: Thu, 1 Oct 2020 14:04:04 GMT Subject: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2] In-Reply-To: References: Message-ID: <02CIxrp2dIe5YnVvBmmVkRuyVxA0hezEUSzcX0zD080=.c29afb6f-7994-4c52-84a6-e979b7a5d761@github.com> On Thu, 1 Oct 2020 12:21:22 GMT, Martin Doerr wrote: > I think this fix deserves a new JBS issue. It doesn't resolve the rounding problem described in JDK-8230664. It fixes > an additional issue. The rounding problem may reoccur when other class layout changes are done. Totally agreed. But, would you mind to create the ticket for me, please? Then, I change the commit header/message. Thank you!! ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From mdoerr at openjdk.java.net Thu Oct 1 15:01:08 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 1 Oct 2020 15:01:08 GMT Subject: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2] In-Reply-To: <02CIxrp2dIe5YnVvBmmVkRuyVxA0hezEUSzcX0zD080=.c29afb6f-7994-4c52-84a6-e979b7a5d761@github.com> References: <02CIxrp2dIe5YnVvBmmVkRuyVxA0hezEUSzcX0zD080=.c29afb6f-7994-4c52-84a6-e979b7a5d761@github.com> Message-ID: <2ZNc3x7LB3mMjwN9ONCccw-vgN-O95tZUcWLGetenOU=.394e3aef-85f6-41ef-861a-621a7fe25f78@github.com> On Thu, 1 Oct 2020 14:01:29 GMT, Ziviani wrote: >> I think this fix deserves a new JBS issue. It doesn't resolve the rounding problem described in JDK-8230664. It fixes >> an additional issue. The rounding problem may reoccur when other class layout changes are done. > >> I think this fix deserves a new JBS issue. It doesn't resolve the rounding problem described in JDK-8230664. It fixes >> an additional issue. The rounding problem may reoccur when other class layout changes are done. > > Totally agreed. But, would you mind to create the ticket for me, please? Then, I change the commit header/message. > Thank you!! Hi Jose, here's your new bug: https://bugs.openjdk.java.net/browse/JDK-8253900 ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From lmesnik at openjdk.java.net Thu Oct 1 15:03:05 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 1 Oct 2020 15:03:05 GMT Subject: Integrated: 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 22:51:59 GMT, Leonid Mesnik wrote: > Test fails with -XX:-TieredCompilation because j.l.Object hasn't been used enough time to trigger compilation. The > default CompileThreshold value is good enough when tiered compilation is enabled (by default) but not for server-only > mode. So it is needed to reduce CompileThreshold to ensure that methods are compiled in any mode. This pull request has now been integrated. Changeset: 84402796 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/84402796 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/447 From cjplummer at openjdk.java.net Thu Oct 1 15:06:05 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 1 Oct 2020 15:06:05 GMT Subject: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2] In-Reply-To: <02CIxrp2dIe5YnVvBmmVkRuyVxA0hezEUSzcX0zD080=.c29afb6f-7994-4c52-84a6-e979b7a5d761@github.com> References: <02CIxrp2dIe5YnVvBmmVkRuyVxA0hezEUSzcX0zD080=.c29afb6f-7994-4c52-84a6-e979b7a5d761@github.com> Message-ID: On Thu, 1 Oct 2020 14:01:29 GMT, Ziviani wrote: > I think this fix deserves a new JBS issue. It doesn't resolve the rounding problem described in JDK-8230664. It fixes > an additional issue. The rounding problem may reoccur when other class layout changes are done. Does it still need to be problem listed due to this issue? I guess it may or may not be an issue based on the current size InstanceKlass, so probably best to keep in problem listed. ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From vkempik at openjdk.java.net Thu Oct 1 15:09:09 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 1 Oct 2020 15:09:09 GMT Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification Message-ID: Please review this change for hotspot and one test. There is few JVMTI callback/event functions in jdk which signature doesn't match specification. for example: static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, jboolean* enabled, ...) but according to jvmti specs it should be: static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, ...) same with ClassUnload(jvmtiEnv* jvmti_env, JNIEnv* jni_env, const char* name, ...) in tests for many years that didn't matter but with coming JEP-391 it becomes important to make it match the spec https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code This commit makes the above mentioned functions to have signature matching jvmti specification ------------- Commit messages: - 8253899: Make IsClassUnloadingEnabled signature match specification + jcheck - 8253899: Make IsClassUnloadingEnabled signature match specification Changes: https://git.openjdk.java.net/jdk/pull/466/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=466&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253899 Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/466/head:pull/466 PR: https://git.openjdk.java.net/jdk/pull/466 From mdoerr at openjdk.java.net Thu Oct 1 15:18:05 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 1 Oct 2020 15:18:05 GMT Subject: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2] In-Reply-To: References: <02CIxrp2dIe5YnVvBmmVkRuyVxA0hezEUSzcX0zD080=.c29afb6f-7994-4c52-84a6-e979b7a5d761@github.com> Message-ID: On Thu, 1 Oct 2020 15:02:55 GMT, Chris Plummer wrote: >>> I think this fix deserves a new JBS issue. It doesn't resolve the rounding problem described in JDK-8230664. It fixes >>> an additional issue. The rounding problem may reoccur when other class layout changes are done. >> >> Totally agreed. But, would you mind to create the ticket for me, please? Then, I change the commit header/message. >> Thank you!! > >> I think this fix deserves a new JBS issue. It doesn't resolve the rounding problem described in JDK-8230664. It fixes >> an additional issue. The rounding problem may reoccur when other class layout changes are done. > > Does it still need to be problem listed due to this issue? I guess it may or may not be an issue based on the current > size InstanceKlass, so probably best to keep in problem listed. If these tests are currently passing with Jose's fix, I suggest to comment them out in the problem list with a note that we may need to disable them again because of JDK-8230664. This way we can test the functionality Jose is fixing until then. And we'll see when the issue comes up again. ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From luhenry at microsoft.com Thu Oct 1 15:48:12 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Thu, 1 Oct 2020 15:48:12 +0000 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] In-Reply-To: References: Message-ID: Hi, As we now have a whole bunch of reviews (thank you all!), we would need a sponsor to get it merged. Thank you :) ------------- PR: https://github.com/openjdk/jdk/pull/212 From github.com+670087+jrziviani at openjdk.java.net Thu Oct 1 16:20:12 2020 From: github.com+670087+jrziviani at openjdk.java.net (Ziviani) Date: Thu, 1 Oct 2020 16:20:12 GMT Subject: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v3] In-Reply-To: References: Message-ID: > TestInstanceKlassSize was failing because, for PowerPC, the following code (instanceKlass.cpp) always compiles to > `return false;` bool InstanceKlass::has_stored_fingerprint() const { > #if INCLUDE_AOT > return should_store_fingerprint() || is_shared(); > #else > return false; > #endif > } > However, in `hasStoredFingerprint()@InstanceKlass.java` the condition `shouldStoreFingerprint() || isShared();` is > always evaluated and may return true (_AFAIK isShared() returns true_). Such condition adds 8 bytes in the > `getSize()@InstanceKlass.java` causing the failure in TestInstanceKlassSize: public long getSize() { // in number of > bytes > ... > if (hasStoredFingerprint()) { > size += 8; // uint64_t > } > return alignSize(size); > } > Considering these tests are failing for PowerPC only (_based on ProblemList.txt_), my solution checks if > `hasStoredFingerprint()` is running on a PowerPC platform. I decided to go this way because there is no existing flag > informing whether AOT is included or not and creating a new one just to handle the PowerPC case seems too much. This > patch is an attempt to fix https://bugs.openjdk.java.net/browse/JDK-8230664 Ziviani has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8253900: SA: wrong size computation when JVM was built without AOT The code hasStoredFingerprint() at InstanceKlass.java is not considering AOT disabled at compilation time, like has_stored_fingerprint() at instanceKlass.cpp does. Such difference can cause TestInstanceKlassSize failures because all objects will have an extra 8-bytes. ------------- Changes: https://git.openjdk.java.net/jdk/pull/358/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=358&range=02 Stats: 32 lines in 6 files changed: 29 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/358.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/358/head:pull/358 PR: https://git.openjdk.java.net/jdk/pull/358 From github.com+670087+jrziviani at openjdk.java.net Thu Oct 1 16:40:06 2020 From: github.com+670087+jrziviani at openjdk.java.net (Ziviani) Date: Thu, 1 Oct 2020 16:40:06 GMT Subject: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v2] In-Reply-To: References: <02CIxrp2dIe5YnVvBmmVkRuyVxA0hezEUSzcX0zD080=.c29afb6f-7994-4c52-84a6-e979b7a5d761@github.com> Message-ID: On Thu, 1 Oct 2020 15:15:09 GMT, Martin Doerr wrote: > If these tests are currently passing with Jose's fix, I suggest to comment them out in the problem list with a note > that we may need to disable them again because of JDK-8230664. This way we can test the functionality Jose is fixing > until then. And we'll see when the issue comes up again. Done! Please, check if you're fine with this: +# The solution to bug JDK-8253900 seems to fix tests TestInstanceKlassSize and +# TestInstanceKlassSizeForInterface. However, while JDK-8230664 is not resolved, +# these tests may be disabled again if necessary. +# serviceability/sa/TestInstanceKlassSize.java 8230664 linux-ppc64le,linux-ppc64 +# serviceability/sa/TestInstanceKlassSizeForInterface.java 8230664 linux-ppc64le,linux-ppc64 Thank you Martin! ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From cjplummer at openjdk.java.net Thu Oct 1 19:25:06 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 1 Oct 2020 19:25:06 GMT Subject: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v2] In-Reply-To: References: <02CIxrp2dIe5YnVvBmmVkRuyVxA0hezEUSzcX0zD080=.c29afb6f-7994-4c52-84a6-e979b7a5d761@github.com> Message-ID: On Thu, 1 Oct 2020 16:37:11 GMT, Ziviani wrote: > > If these tests are currently passing with Jose's fix, I suggest to comment them out in the problem list with a note > > that we may need to disable them again because of JDK-8230664. This way we can test the functionality Jose is fixing > > until then. And we'll see when the issue comes up again. > > Done! Please, check if you're fine with this: > > ``` > +# The solution to bug JDK-8253900 seems to fix tests TestInstanceKlassSize and > +# TestInstanceKlassSizeForInterface. However, while JDK-8230664 is not resolved, > +# these tests may be disabled again if necessary. > +# serviceability/sa/TestInstanceKlassSize.java 8230664 linux-ppc64le,linux-ppc64 > +# serviceability/sa/TestInstanceKlassSizeForInterface.java 8230664 linux-ppc64le,linux-ppc64 > ``` I don't believe there are any other cases were we comment out a test in a problem list. I think it would be best just to remove it completely from ProblemList.txt. JDK-8230664 will still be filed. I suggest maybe adding a comment there saying that the test was removed from the problem list when JDK-8253900 was fixed, but should be re-added if JDK-8230664 starts to reproduce again. ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From sspitsyn at openjdk.java.net Thu Oct 1 20:22:08 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 1 Oct 2020 20:22:08 GMT Subject: RFR: 8252537: Updated @exception with @throws [v4] In-Reply-To: <1uaoGmT1-Bw11W4ki15HeUk6PPmAPnHC4kK5nOu4K2o=.5838a706-9f19-4f00-a481-0430c7dc50b4@github.com> References: <1uaoGmT1-Bw11W4ki15HeUk6PPmAPnHC4kK5nOu4K2o=.5838a706-9f19-4f00-a481-0430c7dc50b4@github.com> Message-ID: On Sun, 27 Sep 2020 12:46:21 GMT, Vipin Sharma wrote: >> Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. >> >> Open Subtasks part of this fix are: >> 1. JDK-8252537 >> 2. JDK-8252539 >> 3. JDK-8252540 >> 4. JDK-8252541 >> >> Previous conversation on this: >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html > > Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision: > > Replaced ... with {@code ...} for modified statement in java.sql Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/95 From github.com+670087+jrziviani at openjdk.java.net Thu Oct 1 20:34:11 2020 From: github.com+670087+jrziviani at openjdk.java.net (Ziviani) Date: Thu, 1 Oct 2020 20:34:11 GMT Subject: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v4] In-Reply-To: References: Message-ID: > TestInstanceKlassSize was failing because, for PowerPC, the following code (instanceKlass.cpp) always compiles to > `return false;` bool InstanceKlass::has_stored_fingerprint() const { > #if INCLUDE_AOT > return should_store_fingerprint() || is_shared(); > #else > return false; > #endif > } > However, in `hasStoredFingerprint()@InstanceKlass.java` the condition `shouldStoreFingerprint() || isShared();` is > always evaluated and may return true (_AFAIK isShared() returns true_). Such condition adds 8 bytes in the > `getSize()@InstanceKlass.java` causing the failure in TestInstanceKlassSize: public long getSize() { // in number of > bytes > ... > if (hasStoredFingerprint()) { > size += 8; // uint64_t > } > return alignSize(size); > } > Considering these tests are failing for PowerPC only (_based on ProblemList.txt_), my solution checks if > `hasStoredFingerprint()` is running on a PowerPC platform. I decided to go this way because there is no existing flag > informing whether AOT is included or not and creating a new one just to handle the PowerPC case seems too much. This > patch is an attempt to fix https://bugs.openjdk.java.net/browse/JDK-8230664 Ziviani has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8253900: SA: wrong size computation when JVM was built without AOT The code hasStoredFingerprint() at InstanceKlass.java is not considering AOT disabled at compilation time, like has_stored_fingerprint() at instanceKlass.cpp does. Such difference can cause TestInstanceKlassSize failures because all objects will have an extra 8-bytes. ------------- Changes: https://git.openjdk.java.net/jdk/pull/358/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=358&range=03 Stats: 30 lines in 6 files changed: 27 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/358.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/358/head:pull/358 PR: https://git.openjdk.java.net/jdk/pull/358 From github.com+670087+jrziviani at openjdk.java.net Thu Oct 1 20:39:05 2020 From: github.com+670087+jrziviani at openjdk.java.net (Ziviani) Date: Thu, 1 Oct 2020 20:39:05 GMT Subject: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v2] In-Reply-To: References: <02CIxrp2dIe5YnVvBmmVkRuyVxA0hezEUSzcX0zD080=.c29afb6f-7994-4c52-84a6-e979b7a5d761@github.com> Message-ID: On Thu, 1 Oct 2020 19:22:24 GMT, Chris Plummer wrote: > ... I suggest maybe adding a comment there saying that the test was removed from the problem list when JDK-8253900 was > fixed, but should be re-added if JDK-8230664 starts to reproduce again. I like this idea because a simple `grep` will be enough to understand what happened. Just pushed my branch, any issue just let me know. Thank you Chris! ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From goetz.lindenmaier at sap.com Thu Oct 1 21:06:35 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Oct 2020 21:06:35 +0000 Subject: RFR: 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation In-Reply-To: References: Message-ID: Hi, Please open up a dummy copy JBS issue without confidential information if you fix a closed, internal Oracle bug. I missed this before, I only saw it is closed when this was pushed today. It is really annoying to still see closed bugs. I had hoped skara would help to avoid this. Please find a way to fix this, so it does not happen all the time! Best regards, Goetz > -----Original Message----- > From: serviceability-dev On > Behalf Of Leonid Mesnik > Sent: Thursday, October 1, 2020 12:58 AM > To: serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:- > TieredCompilation > > On Wed, 30 Sep 2020 22:51:59 GMT, Leonid Mesnik > wrote: > > > Test fails with -XX:+TieredCompilation because j.l.Object hasn't been used > enough time to trigger compilation. So it > > The bug is closed because contain some confidential info. So I explained > issue and fix in this PR description. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/447 From jesper.wilhelmsson at oracle.com Thu Oct 1 21:35:28 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 1 Oct 2020 23:35:28 +0200 Subject: RFR: 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation In-Reply-To: References: Message-ID: <9F94AE3A-9E54-49D9-BEB0-CC9AA3FF8491@oracle.com> I filed https://bugs.openjdk.java.net/browse/SKARA-752 to encourage the Skara team to have the bots check this before allowing integration. /Jesper > On 1 Oct 2020, at 23:06, Lindenmaier, Goetz wrote: > > Hi, > > Please open up a dummy copy JBS issue without confidential > information if you fix a closed, internal Oracle bug. > I missed this before, I only saw it is closed when > this was pushed today. > > It is really annoying to still see closed bugs. > I had hoped skara would help to avoid this. > > Please find a way to fix this, so it does not happen > all the time! > > Best regards, > Goetz > >> -----Original Message----- >> From: serviceability-dev On >> Behalf Of Leonid Mesnik >> Sent: Thursday, October 1, 2020 12:58 AM >> To: serviceability-dev at openjdk.java.net >> Subject: Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:- >> TieredCompilation >> >> On Wed, 30 Sep 2020 22:51:59 GMT, Leonid Mesnik >> wrote: >> >>> Test fails with -XX:+TieredCompilation because j.l.Object hasn't been used >> enough time to trigger compilation. So it >> >> The bug is closed because contain some confidential info. So I explained >> issue and fix in this PR description. >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/447 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From cjplummer at openjdk.java.net Thu Oct 1 21:50:05 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 1 Oct 2020 21:50:05 GMT Subject: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v2] In-Reply-To: References: <02CIxrp2dIe5YnVvBmmVkRuyVxA0hezEUSzcX0zD080=.c29afb6f-7994-4c52-84a6-e979b7a5d761@github.com> Message-ID: On Thu, 1 Oct 2020 20:35:57 GMT, Ziviani wrote: > > ... I suggest maybe adding a comment there saying that the test was removed from the problem list when JDK-8253900 was > > fixed, but should be re-added if JDK-8230664 starts to reproduce again. > > I like this idea because a simple `grep` will be enough to understand what happened. Just pushed my branch, any issue > just let me know. Hi Ziviani, My suggestion was to put the comment in the CR. I really don't think there should be any comment in ProblemList.txt. This is not an uncommon situation. Tests are often removed from the problem list simply because they have not been seen for a while (and we want to determine if the bug is still an issue) or because failures are rare, or possibly even so hard to reproduce that we want to eventually trigger a failure as part of regular testing to help with failure analysis. We have not added comments in the past to document these problem list removals. ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From david.holmes at oracle.com Thu Oct 1 21:50:28 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Oct 2020 07:50:28 +1000 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] In-Reply-To: References: Message-ID: <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com> Hi, On 2/10/2020 1:48 am, Ludovic Henry wrote: > Hi, > > As we now have a whole bunch of reviews (thank you all!), we would need a sponsor to get it merged. The JEP is not yet targeted so we have to wait for that formality. But once that happens I can sponsor for you. Also note that the PR references the wrong JEP so can you please edit the description to fix that. Meanwhile I'll see if I can take this for a spin through our internal testing. Cheers, David ----- > Thank you :) > > ------------- > > PR: https://github.com/openjdk/jdk/pull/212 > From luhenry at microsoft.com Thu Oct 1 21:56:53 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Thu, 1 Oct 2020 21:56:53 +0000 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] In-Reply-To: <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com> References: <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com> Message-ID: Hi David, > The JEP is not yet targeted so we have to wait for that formality. But once that happens I can sponsor for you. Perfect, I didn't know about the need for the JEP to be targeted before the merge. > Also note that the PR references the wrong JEP so can you please edit the description to fix that. I'll work with @Monica to update the PR's description to point to https://openjdk.java.net/jeps/391 instead. Thank you! Ludovic From david.holmes at oracle.com Thu Oct 1 22:49:24 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Oct 2020 08:49:24 +1000 Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification In-Reply-To: References: Message-ID: <067adc98-e612-a1b2-63c2-ea84232941b4@oracle.com> Hi Vladimir, On 2/10/2020 1:09 am, Vladimir Kempik wrote: > Please review this change for hotspot and one test. > There is few JVMTI callback/event functions in jdk which signature doesn't match specification. > for example: > static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, jboolean* enabled, ...) > but according to jvmti specs it should be: > static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, ...) > same with ClassUnload(jvmtiEnv* jvmti_env, JNIEnv* jni_env, const char* name, ...) in tests Sorry I'm missing something - where in the specification is this? This is an extension event and I don't see it documented. Thanks, David > for many years that didn't matter but with coming JEP-391 it becomes important to make it match the spec > https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code > This commit makes the above mentioned functions to have signature matching jvmti specification > > ------------- > > Commit messages: > - 8253899: Make IsClassUnloadingEnabled signature match specification + jcheck > - 8253899: Make IsClassUnloadingEnabled signature match specification > > Changes: https://git.openjdk.java.net/jdk/pull/466/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=466&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8253899 > Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jdk/pull/466.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/466/head:pull/466 > > PR: https://git.openjdk.java.net/jdk/pull/466 > From github.com+670087+jrziviani at openjdk.java.net Fri Oct 2 02:40:16 2020 From: github.com+670087+jrziviani at openjdk.java.net (Ziviani) Date: Fri, 2 Oct 2020 02:40:16 GMT Subject: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v5] In-Reply-To: References: Message-ID: > TestInstanceKlassSize was failing because, for PowerPC, the following code (instanceKlass.cpp) always compiles to > `return false;` bool InstanceKlass::has_stored_fingerprint() const { > #if INCLUDE_AOT > return should_store_fingerprint() || is_shared(); > #else > return false; > #endif > } > However, in `hasStoredFingerprint()@InstanceKlass.java` the condition `shouldStoreFingerprint() || isShared();` is > always evaluated and may return true (_AFAIK isShared() returns true_). Such condition adds 8 bytes in the > `getSize()@InstanceKlass.java` causing the failure in TestInstanceKlassSize: public long getSize() { // in number of > bytes > ... > if (hasStoredFingerprint()) { > size += 8; // uint64_t > } > return alignSize(size); > } > Considering these tests are failing for PowerPC only (_based on ProblemList.txt_), my solution checks if > `hasStoredFingerprint()` is running on a PowerPC platform. I decided to go this way because there is no existing flag > informing whether AOT is included or not and creating a new one just to handle the PowerPC case seems too much. This > patch is an attempt to fix https://bugs.openjdk.java.net/browse/JDK-8230664 Ziviani has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8253900: SA: wrong size computation when JVM was built without AOT The code hasStoredFingerprint() at InstanceKlass.java is not considering AOT disabled at compilation time, like has_stored_fingerprint() at instanceKlass.cpp does. Such difference can cause TestInstanceKlassSize failures because all objects will have an extra 8-bytes. TestInstanceKlassSize and TestInstanceKlassSizeForInterface were removed from ProblemList.txt because it cannot be reproduced after this change, but, if JDK-8230664 starts to reproduce again, these tests can be disabled. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/358/files - new: https://git.openjdk.java.net/jdk/pull/358/files/5c08095f..8e9d1368 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=358&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=358&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/358.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/358/head:pull/358 PR: https://git.openjdk.java.net/jdk/pull/358 From github.com+670087+jrziviani at openjdk.java.net Fri Oct 2 02:40:16 2020 From: github.com+670087+jrziviani at openjdk.java.net (Ziviani) Date: Fri, 2 Oct 2020 02:40:16 GMT Subject: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v2] In-Reply-To: References: <02CIxrp2dIe5YnVvBmmVkRuyVxA0hezEUSzcX0zD080=.c29afb6f-7994-4c52-84a6-e979b7a5d761@github.com> Message-ID: On Thu, 1 Oct 2020 21:47:01 GMT, Chris Plummer wrote: > My suggestion was to put the comment in the CR. I really don't think there should be any comment in ProblemList.txt. > This is not an uncommon situation. Tests are often removed from the problem list simply because they have not been seen > for a while (and we want to determine if the bug is still an issue) or because failures are rare, or possibly even so > hard to reproduce that we want to eventually trigger a failure as part of regular testing to help with failure > analysis. We have not added comments in the past to document these problem list removals. It's clear now. Sorry for the confusion. :-). I removed the tests from problemlist again and add a comment in my commit message. Any `git blame` will easily find it. Hope I did it right now :-D Thanks Chris! ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From daniel.daugherty at oracle.com Thu Oct 1 22:05:03 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 1 Oct 2020 18:05:03 -0400 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] In-Reply-To: References: <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com> Message-ID: So I'm confused... this PR is associated with this bug ID: > > Issue > > * JDK-8248238 : > Implementation of JEP: Windows AArch64 Support > and JDK-8248238 is associated with this JEP: > JDK-8248496 JEP > 388: Windows/AArch64 Port Am I missing something here? Dan On 10/1/20 5:56 PM, Ludovic Henry wrote: > Hi David, > >> The JEP is not yet targeted so we have to wait for that formality. But once that happens I can sponsor for you. > Perfect, I didn't know about the need for the JEP to be targeted before the merge. > >> Also note that the PR references the wrong JEP so can you please edit the description to fix that. > I'll work with @Monica to update the PR's description to point to https://openjdk.java.net/jeps/391 instead. > > Thank you! > Ludovic > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luhenry at microsoft.com Thu Oct 1 22:14:16 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Thu, 1 Oct 2020 22:14:16 +0000 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] In-Reply-To: References: <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com> Message-ID: It?s me who made a mistake. This PR should be associated with JEP 388 as you are rightly pointing out. From: Daniel D. Daugherty Sent: Thursday, October 1, 2020 3:05 PM To: Ludovic Henry ; David Holmes ; David Holmes ; Andrew Haley ; Chris Plummer ; Magnus Ihse Bursie ; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; shenandoah-dev at openjdk.java.net; Monica Beckwith Subject: Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] So I'm confused... this PR is associated with this bug ID: Issue * JDK-8248238: Implementation of JEP: Windows AArch64 Support and JDK-8248238 is associated with this JEP: JDK-8248496 JEP 388: Windows/AArch64 Port Am I missing something here? Dan On 10/1/20 5:56 PM, Ludovic Henry wrote: Hi David, The JEP is not yet targeted so we have to wait for that formality. But once that happens I can sponsor for you. Perfect, I didn't know about the need for the JEP to be targeted before the merge. Also note that the PR references the wrong JEP so can you please edit the description to fix that. I'll work with @Monica to update the PR's description to point to https://openjdk.java.net/jeps/391 instead. Thank you! Ludovic -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjplummer at openjdk.java.net Fri Oct 2 03:36:04 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 2 Oct 2020 03:36:04 GMT Subject: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v5] In-Reply-To: References: Message-ID: <-CBayWf5LBODPitJO2x4vQNdr7_BSUhoo0SH_1oJlUE=.dda4c9d9-aba3-4d49-8a6b-35c33463bd8e@github.com> On Fri, 2 Oct 2020 02:40:16 GMT, Ziviani wrote: >> TestInstanceKlassSize was failing because, for PowerPC, the following code (instanceKlass.cpp) always compiles to >> `return false;` bool InstanceKlass::has_stored_fingerprint() const { >> #if INCLUDE_AOT >> return should_store_fingerprint() || is_shared(); >> #else >> return false; >> #endif >> } >> However, in `hasStoredFingerprint()@InstanceKlass.java` the condition `shouldStoreFingerprint() || isShared();` is >> always evaluated and may return true (_AFAIK isShared() returns true_). Such condition adds 8 bytes in the >> `getSize()@InstanceKlass.java` causing the failure in TestInstanceKlassSize: public long getSize() { // in number of >> bytes >> ... >> if (hasStoredFingerprint()) { >> size += 8; // uint64_t >> } >> return alignSize(size); >> } >> Considering these tests are failing for PowerPC only (_based on ProblemList.txt_), my solution checks if >> `hasStoredFingerprint()` is running on a PowerPC platform. I decided to go this way because there is no existing flag >> informing whether AOT is included or not and creating a new one just to handle the PowerPC case seems too much. This >> patch is an attempt to fix https://bugs.openjdk.java.net/browse/JDK-8230664 > > Ziviani has refreshed the contents of this pull request, and previous commits have been removed. The incremental views > will show differences compared to the previous content of the PR. Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/358 From sspitsyn at openjdk.java.net Fri Oct 2 04:50:04 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 2 Oct 2020 04:50:04 GMT Subject: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v5] In-Reply-To: References: Message-ID: <0pw_Crky-y-0bmejUyDxB1cxuY1ESU_F6EVO4pO4a6U=.60aa8fdc-4d0f-47e3-be57-06f975228c63@github.com> On Fri, 2 Oct 2020 02:40:16 GMT, Ziviani wrote: >> TestInstanceKlassSize was failing because, for PowerPC, the following code (instanceKlass.cpp) always compiles to >> `return false;` bool InstanceKlass::has_stored_fingerprint() const { >> #if INCLUDE_AOT >> return should_store_fingerprint() || is_shared(); >> #else >> return false; >> #endif >> } >> However, in `hasStoredFingerprint()@InstanceKlass.java` the condition `shouldStoreFingerprint() || isShared();` is >> always evaluated and may return true (_AFAIK isShared() returns true_). Such condition adds 8 bytes in the >> `getSize()@InstanceKlass.java` causing the failure in TestInstanceKlassSize: public long getSize() { // in number of >> bytes >> ... >> if (hasStoredFingerprint()) { >> size += 8; // uint64_t >> } >> return alignSize(size); >> } >> Considering these tests are failing for PowerPC only (_based on ProblemList.txt_), my solution checks if >> `hasStoredFingerprint()` is running on a PowerPC platform. I decided to go this way because there is no existing flag >> informing whether AOT is included or not and creating a new one just to handle the PowerPC case seems too much. This >> patch is an attempt to fix https://bugs.openjdk.java.net/browse/JDK-8230664 > > Ziviani has refreshed the contents of this pull request, and previous commits have been removed. The incremental views > will show differences compared to the previous content of the PR. LGTM ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/358 From sspitsyn at openjdk.java.net Fri Oct 2 05:13:02 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 2 Oct 2020 05:13:02 GMT Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 15:02:01 GMT, Vladimir Kempik wrote: > Please review this change for hotspot and one test. > There is few JVMTI callback/event functions in jdk which signature doesn't match specification. > for example: > static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, jboolean* enabled, ...) > but according to jvmti specs it should be: > static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, ...) > same with ClassUnload(jvmtiEnv* jvmti_env, JNIEnv* jni_env, const char* name, ...) in tests > for many years that didn't matter but with coming JEP-391 it becomes important to make it match the spec > https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code > This commit makes the above mentioned functions to have signature matching jvmti specification Vladimir, it looks good to me. David, I think, Vladimir is referring to the JVMTI extension mechanism spec: https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#jvmtiExtensionFunction https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#jvmtiExtensionEvent ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/466 From goetz.lindenmaier at sap.com Fri Oct 2 05:41:46 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 2 Oct 2020 05:41:46 +0000 Subject: RFR: 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation In-Reply-To: <9F94AE3A-9E54-49D9-BEB0-CC9AA3FF8491@oracle.com> References: <9F94AE3A-9E54-49D9-BEB0-CC9AA3FF8491@oracle.com> Message-ID: Hi Jesper, Thanks for opening that issue, if this is implemented it will help a lot! Best regards, Goetz. > -----Original Message----- > From: Jesper Wilhelmsson > Sent: Thursday, October 1, 2020 11:35 PM > To: Lindenmaier, Goetz > Cc: Leonid Mesnik ; serviceability- > dev at openjdk.java.net; jdk-dev at openjdk.java.net > Subject: Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:- > TieredCompilation > > I filed https://bugs.openjdk.java.net/browse/SKARA-752 to encourage the > Skara team to have the bots check this before allowing integration. > /Jesper > > > On 1 Oct 2020, at 23:06, Lindenmaier, Goetz > wrote: > > > > Hi, > > > > Please open up a dummy copy JBS issue without confidential > > information if you fix a closed, internal Oracle bug. > > I missed this before, I only saw it is closed when > > this was pushed today. > > > > It is really annoying to still see closed bugs. > > I had hoped skara would help to avoid this. > > > > Please find a way to fix this, so it does not happen > > all the time! > > > > Best regards, > > Goetz > > > >> -----Original Message----- > >> From: serviceability-dev On > >> Behalf Of Leonid Mesnik > >> Sent: Thursday, October 1, 2020 12:58 AM > >> To: serviceability-dev at openjdk.java.net > >> Subject: Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:- > >> TieredCompilation > >> > >> On Wed, 30 Sep 2020 22:51:59 GMT, Leonid Mesnik > > >> wrote: > >> > >>> Test fails with -XX:+TieredCompilation because j.l.Object hasn't been > used > >> enough time to trigger compilation. So it > >> > >> The bug is closed because contain some confidential info. So I explained > >> issue and fix in this PR description. > >> > >> ------------- > >> > >> PR: https://git.openjdk.java.net/jdk/pull/447 From sspitsyn at openjdk.java.net Fri Oct 2 06:35:05 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 2 Oct 2020 06:35:05 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> Message-ID: On Tue, 8 Sep 2020 07:12:51 GMT, Yasumasa Suenaga wrote: >> If `Agent_OnAttach()` in JVMTI agent which is attempted to load via JVMTI.agent_load dcmd is failed, it would not be >> unloaded. We've [discussed it on >> serviceability-dev](https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032839.html). This PR is >> a continuation of that. This PR also includes to call `Agent_OnUnload()` when `Agent_OnAttach()` failed. >> >> How to reproduce: >> >> 1. Build JVMTI agent for test >> $ git clone https://github.com/YaSuenag/jvmti-examples.git >> $ cd jvmti-examples/helloworld/out/build >> $ cmake ../.. >> >> 2. Run JShell >> >> 3. Load JVMTI agent via `jcmd JVMTI.agent_load` with "error" ("error" means `Agent_OnAttach()` returns JNI_ERR) >> $ jcmd >> 89456 jdk.jshell.execution.RemoteExecutionControl 45651 >> 89547 sun.tools.jcmd.JCmd >> 89436 jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider >> $ jcmd 89436 JVMTI.agent_load `pwd`/libhelloworld.so error >> 89436: >> return code: -1 >> >> 4. Check loaded libraries via `jcmd VM.dynlibs` >> $ jcmd 89436 VM.dynlibs | grep libhelloworld >> 7f2f8b06b000-7f2f8b06c000 r--p 00000000 fd:00 11818202 >> /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so 7f2f8b06c000-7f2f8b06d000 r-xp 00001000 >> fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so 7f2f8b06d000-7f2f8b06e000 >> r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so >> 7f2f8b06e000-7f2f8b06f000 r--p 00002000 fd:00 11818202 >> /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so 7f2f8b06f000-7f2f8b070000 rw-p 00003000 >> fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > > @edvbld Can you approve me to run tier1 tests with /test PR command again? I was initially wrong by supporting this, and now I share David's concerns about unclear semantics of this. The questions are: - Q1: Is it necessary to call the Agent_OnUnload()? - Q2: Would it be a JVMTI spec violation to call the Agent_OnAttach() multiple times? (It seems to be the case to me.) - Q3: What has to be done for statically linked agent? - Q4: Should the agent be correctly loadable in the first place? What were the reasons its loading to fail? Yes, at least, a CSR is needed for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/19 From vkempik at openjdk.java.net Fri Oct 2 07:02:03 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Oct 2020 07:02:03 GMT Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification In-Reply-To: References: Message-ID: <5UPvhVjwK3TOKrd2rSzeCz-xT0tXsCUkMT9R8tgFR8I=.f1723d22-6883-4ad3-af55-a7437ef905de@github.com> On Fri, 2 Oct 2020 05:10:20 GMT, Serguei Spitsyn wrote: >> Please review this change for hotspot and one test. >> There is few JVMTI callback/event functions in jdk which signature doesn't match specification. >> for example: >> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, jboolean* enabled, ...) >> but according to jvmti specs it should be: >> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, ...) >> same with ClassUnload(jvmtiEnv* jvmti_env, JNIEnv* jni_env, const char* name, ...) in tests >> for many years that didn't matter but with coming JEP-391 it becomes important to make it match the spec >> https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code >> This commit makes the above mentioned functions to have signature matching jvmti specification > > Vladimir, it looks good to me. > David, > I think, Vladimir is referring to the JVMTI extension mechanism spec: > https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#jvmtiExtensionFunction > https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#jvmtiExtensionEvent Hello Serguei, you are right, I was talking about this documents. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/466 From dholmes at openjdk.java.net Fri Oct 2 07:30:04 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 2 Oct 2020 07:30:04 GMT Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification In-Reply-To: <5UPvhVjwK3TOKrd2rSzeCz-xT0tXsCUkMT9R8tgFR8I=.f1723d22-6883-4ad3-af55-a7437ef905de@github.com> References: <5UPvhVjwK3TOKrd2rSzeCz-xT0tXsCUkMT9R8tgFR8I=.f1723d22-6883-4ad3-af55-a7437ef905de@github.com> Message-ID: On Fri, 2 Oct 2020 06:59:13 GMT, Vladimir Kempik wrote: >> Vladimir, it looks good to me. > >> David, >> I think, Vladimir is referring to the JVMTI extension mechanism spec: >> https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#jvmtiExtensionFunction >> https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#jvmtiExtensionEvent > > Hello Serguei, you are right, I was talking about this documents. > Thank you. Okay but look at the example that documentation gives: > For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates that there is a jint parameter, the event > handler should be declared: > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) The myInt is explicit, just as our "jboolean* enabled" is explicit. I think they key point is that the signature must end with "..." which it does. I don't see anything here that needs to be fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/466 From ysuenaga at openjdk.java.net Fri Oct 2 07:31:03 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 2 Oct 2020 07:31:03 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> Message-ID: <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> On Fri, 2 Oct 2020 06:30:34 GMT, Serguei Spitsyn wrote: > * Q1: Is it necessary to call the Agent_OnUnload()? [JVMTI spec of Agent_OnUnload()](https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#onunload) says this function will be called when the agent library will be unloaded by platform specific mechanism. OTOH it also says `Agent_OnUnload()` will be called both at VM termination and **by other reasons**. The spec don't say for the case if `Agent_OnAttach()` would be failed. IMHO `Agent_OnUnload()` should be called because this PR would unload library if `Agent_OnAttach()` failed. > * Q2: Would it be a JVMTI spec violation to call the Agent_OnAttach() multiple times? (It seems to be the case to me.) `Agent_OnAttach()` should be called only once per attach request, but VM should accept multiple attach request for same agent library. For example, we can add multiple `-agentlib` and `-agentpath` request as below. JVMTI agent might change behavior due to arguments or configuration file. -agentlib:test=profile=A -agentlib:test=profile=B -agentpath:/path/to/libtest=profile=C Agent developers should have responsibility for the behavior when more than one agent is loaded at a time. > * Q3: What has to be done for statically linked agent? JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. > * Q4: Should the agent be correctly loadable in the first place? What were the reasons its loading to fail? Agent (`Agent_OnAttach()`) might fail due to error in agent logic. For example, some agents load configuration file at initialization. If the user gives wrong value, it will fail. > Yes, at least, a CSR is needed for this. I will file CSR for this PR after this discussion. ------------- PR: https://git.openjdk.java.net/jdk/pull/19 From vkempik at openjdk.java.net Fri Oct 2 07:37:03 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Oct 2020 07:37:03 GMT Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification In-Reply-To: References: <5UPvhVjwK3TOKrd2rSzeCz-xT0tXsCUkMT9R8tgFR8I=.f1723d22-6883-4ad3-af55-a7437ef905de@github.com> Message-ID: On Fri, 2 Oct 2020 07:27:17 GMT, David Holmes wrote: > Okay but look at the example that documentation gives: > > > For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates that there is a jint parameter, the event > > handler should be declared: ``` > > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) > > ``` > > The myInt is explicit, just as our "jboolean* enabled" is explicit. I think they key point is that the signature must > end with "..." which it does. > I don't see anything here that needs to be fixed. Hello David. On majority of platforms this would be fine. But on some platforms, variadic arguments and non variadic arguments are passed differently ( for example on macos-aarch64, variadic args are passed always on stack, non variadic on registers (and on stack for 9th+ arg) , that causes issues. If you still see no issues here we can delay and make this changeset part of JEP-391. But since this changeset isn't much macos-aarch64 specific, I thought it would be good to integrate it separately from jep-391. Regards, Vladimir ------------- PR: https://git.openjdk.java.net/jdk/pull/466 From pliden at openjdk.java.net Fri Oct 2 09:00:42 2020 From: pliden at openjdk.java.net (Per Liden) Date: Fri, 2 Oct 2020 09:00:42 GMT Subject: RFR: 8252105: parallel heap inspection for ZCollectedHeap [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 07:24:20 GMT, Lin Zang wrote: >> Hi @pliden, >> Thanks for your comments, I will try to merge ZHeapIterator and ZHeapParIterator and update the pr then. >> -Lin > > Hi @pliden, > I updated the PR which merge the changed code into ZHeapIterator. > May I ask your help to review it ? Thanks. > -Lin Hi @linzang, I started reviewing your patch in more detail. However, I ended up with a large number of major comments and I started to feel that it would probably be more productive to create an alternative patch for this, so I did. https://github.com/openjdk/jdk/compare/master...pliden:8252105_parallel_object_iterator Some of the main differences compared to your proposed patch: * Root scanning is also now done in parallel * Same code paths regardless of number of worker threads used * Arrays are chunked for better work stealing/balance * A terminator is used for better work stealing/balance * All of the functionality is isolated (as much as possible) to ZHeapIterator I think the easiest way forward is probably if you close this PR, and I'll open a new one. ------------- PR: https://git.openjdk.java.net/jdk/pull/103 From afarley at openjdk.java.net Fri Oct 2 09:48:48 2020 From: afarley at openjdk.java.net (Adam Farley) Date: Fri, 2 Oct 2020 09:48:48 GMT Subject: RFR: 8252997: Null-proofing for linker_md.c [v2] In-Reply-To: References: Message-ID: > In the platform-specific implementations of linker_md.c, we see the dll_build_name methods begin with a call to > jvmtiAllocate. > We then appear to rush ahead and try to use that variable without checking for a null. > > I propose moving the null check to the point *before* we try to use that variable, to avoid any possible SEGV. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8252997 Adam Farley has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8252997: Null-proofing for linker_md.c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/246/files - new: https://git.openjdk.java.net/jdk/pull/246/files/89e43419..cfaf382c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=246&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=246&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/246/head:pull/246 PR: https://git.openjdk.java.net/jdk/pull/246 From afarley at openjdk.java.net Fri Oct 2 09:48:48 2020 From: afarley at openjdk.java.net (Adam Farley) Date: Fri, 2 Oct 2020 09:48:48 GMT Subject: RFR: 8252997: Null-proofing for linker_md.c [v2] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 22:25:13 GMT, Chris Plummer wrote: >> Adam Farley has refreshed the contents of this pull request, and previous commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. The pull request contains one new commit since >> the last revision: >> 8252997: Null-proofing for linker_md.c > > Both files need copyright updates before pushing. Otherwise the changes look good. The copyrights have been updated as advised. Apologies for the delay. ------------- PR: https://git.openjdk.java.net/jdk/pull/246 From mdoerr at openjdk.java.net Fri Oct 2 09:52:41 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 2 Oct 2020 09:52:41 GMT Subject: RFR: 8253900: SA: wrong size computation when JVM was built without AOT [v5] In-Reply-To: <0pw_Crky-y-0bmejUyDxB1cxuY1ESU_F6EVO4pO4a6U=.60aa8fdc-4d0f-47e3-be57-06f975228c63@github.com> References: <0pw_Crky-y-0bmejUyDxB1cxuY1ESU_F6EVO4pO4a6U=.60aa8fdc-4d0f-47e3-be57-06f975228c63@github.com> Message-ID: On Fri, 2 Oct 2020 04:46:53 GMT, Serguei Spitsyn wrote: >> Ziviani has refreshed the contents of this pull request, and previous commits have been removed. The incremental views >> will show differences compared to the previous content of the PR. > > LGTM Added comment to JDK-8230664. Test results look good on our side, too. ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From avoitylov at openjdk.java.net Fri Oct 2 13:55:18 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 2 Oct 2020 13:55:18 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v3] In-Reply-To: References: Message-ID: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. Aleksei Voitylov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'JDK-8247589' of https://github.com/voitylov/jdk into JDK-8247589 - JDK-8247589: Implementation of Alpine Linux/x64 Port - JDK-8247589: Implementation of Alpine Linux/x64 Port - JDK-8247589: Implementation of Alpine Linux/x64 Port - JDK-8247589: Implementation of Alpine Linux/x64 Port ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/49/files - new: https://git.openjdk.java.net/jdk/pull/49/files/d5994cb5..705b8555 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=01-02 Stats: 73505 lines in 3006 files changed: 26172 ins; 37386 del; 9947 mod Patch: https://git.openjdk.java.net/jdk/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk/pull/49 From vsharma at openjdk.java.net Fri Oct 2 14:53:41 2020 From: vsharma at openjdk.java.net (Vipin Sharma) Date: Fri, 2 Oct 2020 14:53:41 GMT Subject: Integrated: 8252537: Updated @exception with @throws In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 19:29:30 GMT, Vipin Sharma wrote: > Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536. > > Open Subtasks part of this fix are: > 1. JDK-8252537 > 2. JDK-8252539 > 3. JDK-8252540 > 4. JDK-8252541 > > Previous conversation on this: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html This pull request has now been integrated. Changeset: dffe9db2 Author: Vipin Sharma Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/dffe9db2 Stats: 2109 lines in 86 files changed: 0 ins; 0 del; 2109 mod 8252537: Updated @exception with @throws 8252536: Replace @exception with @throws for core-libs 8252539: Replace @exception with @throws java.rmi.activation package 8252540: Replace @exception with @throws java.rmi.registry package 8252541: Replace @exception with @throws java.rmi.server package Reviewed-by: rriggs, sspitsyn, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/95 From david.holmes at oracle.com Fri Oct 2 15:12:08 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 3 Oct 2020 01:12:08 +1000 Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification In-Reply-To: References: <5UPvhVjwK3TOKrd2rSzeCz-xT0tXsCUkMT9R8tgFR8I=.f1723d22-6883-4ad3-af55-a7437ef905de@github.com> Message-ID: Hi Vladimir, On 2/10/2020 5:37 pm, Vladimir Kempik wrote: > On Fri, 2 Oct 2020 07:27:17 GMT, David Holmes wrote: > >> Okay but look at the example that documentation gives: >> >>> For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates that there is a jint parameter, the event >>> handler should be declared: ``` >>> void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) >>> ``` >> >> The myInt is explicit, just as our "jboolean* enabled" is explicit. I think they key point is that the signature must >> end with "..." which it does. >> I don't see anything here that needs to be fixed. > > Hello David. On majority of platforms this would be fine. > > But on some platforms, variadic arguments and non variadic arguments are passed differently ( for example on > macos-aarch64, variadic args are passed always on stack, non variadic on registers (and on stack for 9th+ arg) , that > causes issues. Okay - I see the potential for a problme here but ... > If you still see no issues here we can delay and make this changeset part of JEP-391. > But since this changeset isn't much macos-aarch64 specific, I thought it would be good to integrate it separately from > jep-391. ... this change actually goes against the example in the spec, so if you make this change it indicates the spec needs to be updated too. Cheers, David ----- > Regards, Vladimir > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/466 > From vkempik at openjdk.java.net Fri Oct 2 15:29:38 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 2 Oct 2020 15:29:38 GMT Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification In-Reply-To: References: <5UPvhVjwK3TOKrd2rSzeCz-xT0tXsCUkMT9R8tgFR8I=.f1723d22-6883-4ad3-af55-a7437ef905de@github.com> Message-ID: On Fri, 2 Oct 2020 07:34:45 GMT, Vladimir Kempik wrote: >> Okay but look at the example that documentation gives: >> >>> For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates that there is a jint parameter, the event >>> handler should be declared: >>> void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) >> >> The myInt is explicit, just as our "jboolean* enabled" is explicit. I think they key point is that the signature must >> end with "..." which it does. >> I don't see anything here that needs to be fixed. > >> Okay but look at the example that documentation gives: >> >> > For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates that there is a jint parameter, the event >> > handler should be declared: ``` >> > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) >> > ``` >> >> The myInt is explicit, just as our "jboolean* enabled" is explicit. I think they key point is that the signature must >> end with "..." which it does. >> I don't see anything here that needs to be fixed. > > Hello David. On majority of platforms this would be fine. > > But on some platforms, variadic arguments and non variadic arguments are passed differently ( for example on > macos-aarch64, variadic args are passed always on stack, non variadic on registers (and on stack for 9th+ arg) , that > causes issues. If you still see no issues here we can delay and make this changeset part of JEP-391. > But since this changeset isn't much macos-aarch64 specific, I thought it would be good to integrate it separately from > jep-391. > Regards, Vladimir > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on > [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ > Hi Vladimir, > > On 2/10/2020 5:37 pm, Vladimir Kempik wrote: > > > On Fri, 2 Oct 2020 07:27:17 GMT, David Holmes wrote: > > > Okay but look at the example that documentation gives: > > > > For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates that there is a jint parameter, the event > > > > handler should be declared: ``` > > > > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) > > > > ``` > > > > > > > > > The myInt is explicit, just as our "jboolean* enabled" is explicit. I think they key point is that the signature must > > > end with "..." which it does. > > > I don't see anything here that needs to be fixed. > > > > > > Hello David. On majority of platforms this would be fine. > > But on some platforms, variadic arguments and non variadic arguments are passed differently ( for example on > > macos-aarch64, variadic args are passed always on stack, non variadic on registers (and on stack for 9th+ arg) , that > > causes issues. > > Okay - I see the potential for a problme here but ... > > > If you still see no issues here we can delay and make this changeset part of JEP-391. > > But since this changeset isn't much macos-aarch64 specific, I thought it would be good to integrate it separately from > > jep-391. > > ... this change actually goes against the example in the spec, so if you > make this change it indicates the spec needs to be updated too. > > Cheers, > David > ----- Hello David I really believe the problem is in document here ( in examples) first, the doc clearly specify the type typedef jvmtiError (JNICALL *jvmtiExtensionFunction) (jvmtiEnv* jvmti_env, ...); then in examples it declares the function not matching this spec. Is it a good idea to update the docs in a separate bug ? Thanks, Vladimir ------------- PR: https://git.openjdk.java.net/jdk/pull/466 From avoitylov at openjdk.java.net Fri Oct 2 15:39:09 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 2 Oct 2020 15:39:09 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v4] In-Reply-To: References: Message-ID: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: test2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/49/files - new: https://git.openjdk.java.net/jdk/pull/49/files/705b8555..5feda5ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk/pull/49 From avoitylov at openjdk.java.net Fri Oct 2 15:45:56 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 2 Oct 2020 15:45:56 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v5] In-Reply-To: References: Message-ID: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. Aleksei Voitylov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/49/files - new: https://git.openjdk.java.net/jdk/pull/49/files/5feda5ff..b7ffed87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk/pull/49 From sgehwolf at openjdk.java.net Fri Oct 2 16:41:49 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Oct 2020 16:41:49 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) Message-ID: An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the affected system, `/proc/self/mountinfo` contains a line such as this one: 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd Note that `/proc/cgroups` looks like this: #subsys_name hierarchy num_cgroups enabled cpuset 0 1 1 cpu 0 1 1 cpuacct 0 1 1 blkio 0 1 1 memory 0 1 1 devices 0 1 1 freezer 0 1 1 net_cls 0 1 1 perf_event 0 1 1 net_prio 0 1 1 hugetlb 0 1 1 pids 0 1 1 This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and look for `cgroup` FS-type lines which aren't also mounted purely for systemd. **Testing** - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) - [x] Added regression test which fails prior the patch and passes after - [ ] Submit testing (still running) ------------- Commit messages: - 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) Changes: https://git.openjdk.java.net/jdk/pull/485/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245543 Stats: 89 lines in 4 files changed: 83 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Fri Oct 2 16:41:49 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Oct 2020 16:41:49 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 16:34:49 GMT, Severin Gehwolf wrote: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and > look for `cgroup` FS-type lines which aren't also mounted purely for systemd. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [ ] Submit testing (still running) @bulasevich Do you want to give this a spin? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sspitsyn at openjdk.java.net Fri Oct 2 16:53:46 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 2 Oct 2020 16:53:46 GMT Subject: RFR: 8252997: Null-proofing for linker_md.c [v2] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 09:48:48 GMT, Adam Farley wrote: >> In the platform-specific implementations of linker_md.c, we see the dll_build_name methods begin with a call to >> jvmtiAllocate. >> We then appear to rush ahead and try to use that variable without checking for a null. >> >> I propose moving the null check to the point *before* we try to use that variable, to avoid any possible SEGV. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8252997 > > Adam Farley has refreshed the contents of this pull request, and previous commits have been removed. The incremental > views will show differences compared to the previous content of the PR. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/246 From mbeckwit at openjdk.java.net Fri Oct 2 17:20:45 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Fri, 2 Oct 2020 17:20:45 GMT Subject: RFR: 8248238: Implementation: JEP 388: Windows AArch64 Support [v12] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 00:40:29 GMT, David Holmes wrote: >> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: >> >> change string representation for r18 to "r18_tls" on every platform > > Marked as reviewed by dholmes (Reviewer). > The JEP is not yet targeted so we have to wait for that formality. But > once that happens I can sponsor for you. Thanks. > > Also note that the PR references the wrong JEP so can you please edit > the description to fix that. Added JEP # (388) here and updated the JBS entry. After looking at JEPs 386, 377, and 379, I also did the following: - listed JDK-8248238 as a sub-task for JDK-8248496 - added this PR link in a comment for the JEP. As soon as the JEP is targetted, I will update the "Fix version" for the 'Implementation' (JDK-8248238) and ping you @dholmes-ora . > > Meanwhile I'll see if I can take this for a spin through our internal > testing. Thanks so much. Regards, Monica > > Cheers, > David ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From bulasevich at openjdk.java.net Sun Oct 4 18:17:38 2020 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Sun, 4 Oct 2020 18:17:38 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> On Fri, 2 Oct 2020 16:34:49 GMT, Severin Gehwolf wrote: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and > look for `cgroup` FS-type lines which aren't also mounted purely for systemd. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [ ] Submit testing (still running) src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 72: > 70: * Pattern explanation: > 71: * > 72: * /`````\ /`````\ /`````\ /```````\ /```````\ /```\ (8) /```````\ (10) + (11) Alternatively, consider the inline comment: private static final Pattern MOUNTINFO_PATTERN = Pattern.compile( "^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+" + // (1) + (2) + (3) "([^\\s]+)\\s+([^\\s]+)\\s+" + // (4) + (5) - group 1,2: mount point, mount options "[^-]+-\\s+" + // (6) + (7) + (8) "([^\\s]+)\\s+" + // (9) - group 3: fstype ".*$"); // (10) + (11) src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 80: > 78: */ > 79: private static final Pattern MOUNTINFO_PATTERN = > 80: > Pattern.compile("^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+([^\\s]+)\\s+([^\\s]+)\\s+[^-]+-\\s+([^\\s]+)\\s+.*$"); Only group_3 = fstype is used in the pattern, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From bulasevich at openjdk.java.net Sun Oct 4 18:17:37 2020 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Sun, 4 Oct 2020 18:17:37 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 16:39:09 GMT, Severin Gehwolf wrote: >> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd >> >> >> Note that `/proc/cgroups` looks like this: >> >> #subsys_name hierarchy num_cgroups enabled >> cpuset 0 1 1 >> cpu 0 1 1 >> cpuacct 0 1 1 >> blkio 0 1 1 >> memory 0 1 1 >> devices 0 1 1 >> freezer 0 1 1 >> net_cls 0 1 1 >> perf_event 0 1 1 >> net_prio 0 1 1 >> hugetlb 0 1 1 >> pids 0 1 1 >> >> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo >> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in >> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, >> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to >> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's >> cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and >> look for `cgroup` FS-type lines which aren't also mounted purely for systemd. >> **Testing** >> >> - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) >> - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) >> - [x] Added regression test which fails prior the patch and passes after >> - [ ] Submit testing (still running) > > @bulasevich Do you want to give this a spin? The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From dholmes at openjdk.java.net Mon Oct 5 03:24:44 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 5 Oct 2020 03:24:44 GMT Subject: RFR: 8248238: Implementation: JEP 388: Windows AArch64 Support [v12] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 17:16:50 GMT, Monica Beckwith wrote: >> Marked as reviewed by dholmes (Reviewer). > >> The JEP is not yet targeted so we have to wait for that formality. But >> once that happens I can sponsor for you. > > Thanks. >> >> Also note that the PR references the wrong JEP so can you please edit >> the description to fix that. > > Added JEP # (388) here and updated the JBS entry. > After looking at JEPs 386, 377, and 379, I also did the following: > - listed JDK-8248238 as a sub-task for JDK-8248496 > - added this PR link in a comment for the JEP. > > As soon as the JEP is targetted, I will update the "Fix version" for the 'Implementation' (JDK-8248238) and ping you > @dholmes-ora . >> >> Meanwhile I'll see if I can take this for a spin through our internal >> testing. > Thanks so much. > > Regards, > Monica > >> >> Cheers, >> David @mo-beck The initial comment still has this incorrect link: [2] https://openjdk.java.net/jeps/8251280 Please edit the comment and fix the link. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From mbeckwit at openjdk.java.net Mon Oct 5 03:24:45 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 5 Oct 2020 03:24:45 GMT Subject: Integrated: 8248238: Implementation: JEP 388: Windows AArch64 Support In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith wrote: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 This pull request has now been integrated. Changeset: 9604ee82 Author: Monica Beckwith Committer: David Holmes URL: https://git.openjdk.java.net/jdk/commit/9604ee82 Stats: 2566 lines in 62 files changed: 2208 ins; 126 del; 232 mod 8248238: Implementation: JEP 388: Windows AArch64 Support Co-authored-by: Monica Beckwith Co-authored-by: Ludovic Henry Co-authored-by: Bernhard Urban-Forster Reviewed-by: dholmes, cjplummer, aph, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From david.holmes at oracle.com Mon Oct 5 04:00:40 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 5 Oct 2020 14:00:40 +1000 Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification In-Reply-To: References: <5UPvhVjwK3TOKrd2rSzeCz-xT0tXsCUkMT9R8tgFR8I=.f1723d22-6883-4ad3-af55-a7437ef905de@github.com> Message-ID: <3ac4f938-71ec-ddf7-ed27-7fafe8a0c204@oracle.com> Hi Vladimir, On 3/10/2020 1:29 am, Vladimir Kempik wrote: > On Fri, 2 Oct 2020 07:34:45 GMT, Vladimir Kempik wrote: >>> If you still see no issues here we can delay and make this changeset part of JEP-391. >>> But since this changeset isn't much macos-aarch64 specific, I thought it would be good to integrate it separately from >>> jep-391. >> >> ... this change actually goes against the example in the spec, so if you >> make this change it indicates the spec needs to be updated too. >> >> Cheers, >> David >> ----- > > Hello David > > I really believe the problem is in document here ( in examples) > first, the doc clearly specify the type > > typedef jvmtiError (JNICALL *jvmtiExtensionFunction) > (jvmtiEnv* jvmti_env, > ...); > > then in examples it declares the function not matching this spec. > > Is it a good idea to update the docs in a separate bug ? I don't think it really matters one way or the other as long as any new bug is promptly fixed. At the moment the code matches the example in the spec but they are both "wrong". I'd like to see them both "right" asap. Thanks, David > Thanks, Vladimir > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/466 > From mbeckwit at openjdk.java.net Mon Oct 5 04:11:47 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 5 Oct 2020 04:11:47 GMT Subject: RFR: 8248238: Implementation: JEP 388: Windows AArch64 Support [v12] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 03:20:43 GMT, David Holmes wrote: > @mo-beck The initial comment still has this incorrect link: > > [2] https://openjdk.java.net/jeps/8251280 > > Please edit the comment and fix the link. That was a link to the macOS + Arm64 port. But I have removed it as it wasn't needed in the description of this implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From sgehwolf at openjdk.java.net Mon Oct 5 08:39:47 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 08:39:47 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v2] In-Reply-To: References: Message-ID: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and > look for `cgroup` FS-type lines which aren't also mounted purely for systemd. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [ ] Submit testing (still running) Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/b7c7f510..6c4fadd1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=00-01 Stats: 17 lines in 1 file changed: 4 ins; 10 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Mon Oct 5 08:39:48 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 08:39:48 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v2] In-Reply-To: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> References: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> Message-ID: On Sun, 4 Oct 2020 18:12:14 GMT, Boris Ulasevich wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 72: > >> 70: * Pattern explanation: >> 71: * >> 72: * /`````\ /`````\ /`````\ /```````\ /```````\ /```\ (8) /```````\ (10) + (11) > > Alternatively, consider the inline comment: > > private static final Pattern MOUNTINFO_PATTERN = Pattern.compile( > "^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+" + // (1) + (2) + (3) > "([^\\s]+)\\s+([^\\s]+)\\s+" + // (4) + (5) - group 1,2: mount point, mount options > "[^-]+-\\s+" + // (6) + (7) + (8) > "([^\\s]+)\\s+" + // (9) - group 3: fstype > ".*$"); // (10) + (11) Good suggestion. I've changed it to what you've suggested and removed the unused groups 1 and 2. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Mon Oct 5 09:02:37 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 09:02:37 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Sun, 4 Oct 2020 18:14:37 GMT, Boris Ulasevich wrote: > The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed. Thanks for the review and for testing it! ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Mon Oct 5 09:02:38 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 09:02:38 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v2] In-Reply-To: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> References: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> Message-ID: On Sun, 4 Oct 2020 18:12:39 GMT, Boris Ulasevich wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 80: > >> 78: */ >> 79: private static final Pattern MOUNTINFO_PATTERN = >> 80: >> Pattern.compile("^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+([^\\s]+)\\s+([^\\s]+)\\s+[^-]+-\\s+([^\\s]+)\\s+.*$"); > > Only group_3 = fstype is used in the pattern, right? Yes. I've removed unused groups now, though. Originally, my thinking was that `mount root` and `mount path` would be useful too so I kept it in. It would certainly be useful for getting rid of reading `/proc/self/mountinfo` twice on the Java side. As a future enhancement we could do away with double parsing of mount info by keeping track of relevant cgroup controller info. I've filed [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) to track this. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Mon Oct 5 10:12:39 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 10:12:39 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 09:00:17 GMT, Severin Gehwolf wrote: >> The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed. > >> The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed. > > Thanks for the review and for testing it! @bobvandette Could you perhaps have a look at this? Many thanks in advance! ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Mon Oct 5 10:16:49 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 10:16:49 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: References: Message-ID: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and > look for `cgroup` FS-type lines which aren't also mounted purely for systemd. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Fix typo in comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/6c4fadd1..d334ac60 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From eosterlund at openjdk.java.net Mon Oct 5 11:43:52 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 5 Oct 2020 11:43:52 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v10] In-Reply-To: References: Message-ID: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Review: Deal with new assert from mainline - Merge branch 'master' into 8253180_conc_stack_scanning - Review: StackWalker hook - Review: Kim CR 1 and exception handling fix - Review: Move barrier detach - Review: Remove assert that has outstayed its welcome - Merge branch 'master' into 8253180_conc_stack_scanning - Review: Albert CR2 and defensive programming - Review: StefanK CR 3 - Review: Per CR 1 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9604ee82...e633cb94 ------------- Changes: https://git.openjdk.java.net/jdk/pull/296/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=09 Stats: 2740 lines in 131 files changed: 2167 ins; 311 del; 262 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From vkempik at openjdk.java.net Mon Oct 5 12:47:02 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 5 Oct 2020 12:47:02 GMT Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification In-Reply-To: References: <5UPvhVjwK3TOKrd2rSzeCz-xT0tXsCUkMT9R8tgFR8I=.f1723d22-6883-4ad3-af55-a7437ef905de@github.com> Message-ID: On Fri, 2 Oct 2020 15:26:30 GMT, Vladimir Kempik wrote: >>> Okay but look at the example that documentation gives: >>> >>> > For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates that there is a jint parameter, the event >>> > handler should be declared: ``` >>> > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) >>> > ``` >>> >>> The myInt is explicit, just as our "jboolean* enabled" is explicit. I think they key point is that the signature must >>> end with "..." which it does. >>> I don't see anything here that needs to be fixed. >> >> Hello David. On majority of platforms this would be fine. >> >> But on some platforms, variadic arguments and non variadic arguments are passed differently ( for example on >> macos-aarch64, variadic args are passed always on stack, non variadic on registers (and on stack for 9th+ arg) , that >> causes issues. If you still see no issues here we can delay and make this changeset part of JEP-391. >> But since this changeset isn't much macos-aarch64 specific, I thought it would be good to integrate it separately from >> jep-391. >> Regards, Vladimir > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on >> [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ >> Hi Vladimir, >> >> On 2/10/2020 5:37 pm, Vladimir Kempik wrote: >> >> > On Fri, 2 Oct 2020 07:27:17 GMT, David Holmes wrote: >> > > Okay but look at the example that documentation gives: >> > > > For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates that there is a jint parameter, the event >> > > > handler should be declared: ``` >> > > > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) >> > > > ``` >> > > >> > > >> > > The myInt is explicit, just as our "jboolean* enabled" is explicit. I think they key point is that the signature must >> > > end with "..." which it does. >> > > I don't see anything here that needs to be fixed. >> > >> > >> > Hello David. On majority of platforms this would be fine. >> > But on some platforms, variadic arguments and non variadic arguments are passed differently ( for example on >> > macos-aarch64, variadic args are passed always on stack, non variadic on registers (and on stack for 9th+ arg) , that >> > causes issues. >> >> Okay - I see the potential for a problme here but ... >> >> > If you still see no issues here we can delay and make this changeset part of JEP-391. >> > But since this changeset isn't much macos-aarch64 specific, I thought it would be good to integrate it separately from >> > jep-391. >> >> ... this change actually goes against the example in the spec, so if you >> make this change it indicates the spec needs to be updated too. >> >> Cheers, >> David >> ----- > > Hello David > > I really believe the problem is in document here ( in examples) > first, the doc clearly specify the type > > typedef jvmtiError (JNICALL *jvmtiExtensionFunction) > (jvmtiEnv* jvmti_env, > ...); > > then in examples it declares the function not matching this spec. > > Is it a good idea to update the docs in a separate bug ? > > Thanks, Vladimir Hello David I have created CSR draft https://bugs.openjdk.java.net/browse/JDK-8254014 Regards, Vladimir ------------- PR: https://git.openjdk.java.net/jdk/pull/466 From lzang at openjdk.java.net Mon Oct 5 14:31:42 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 5 Oct 2020 14:31:42 GMT Subject: RFR: 8252105: parallel heap inspection for ZCollectedHeap [v2] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 08:57:29 GMT, Per Liden wrote: >> Hi @pliden, >> I updated the PR which merge the changed code into ZHeapIterator. >> May I ask your help to review it ? Thanks. >> -Lin > > Hi @linzang, > > I started reviewing your patch in more detail. However, I ended up with a large number of major comments and I started > to feel that it would probably be more productive to create an alternative patch for this, so I did. > https://github.com/openjdk/jdk/compare/master...pliden:8252105_parallel_object_iterator > > Some of the main differences compared to your proposed patch: > * Root scanning is also now done in parallel > * Same code paths regardless of number of worker threads used > * Arrays are chunked for better work stealing/balance > * A terminator is used for better work stealing/balance > * All of the functionality is isolated (as much as possible) to ZHeapIterator > > I think the easiest way forward is probably if you close this PR, and I'll open a new one. Hi @pliden, Sorry for late reply. I will close this PR and let's discuss in your new one. -Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/103 From lzang at openjdk.java.net Mon Oct 5 14:31:43 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 5 Oct 2020 14:31:43 GMT Subject: Withdrawn: 8252105: parallel heap inspection for ZCollectedHeap In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 02:28:43 GMT, Lin Zang wrote: > - enable parallel heap inspection for ZCollectedHeap > - preliminary evaluation: > Time of jmap histo on 8GB heap with ~5GB objects > * before: 7.103s > * after : 2.734s (with 4 parallel threads) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/103 From pliden at openjdk.java.net Mon Oct 5 15:45:50 2020 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 5 Oct 2020 15:45:50 GMT Subject: RFR: 8252105: parallel heap inspection for ZCollectedHeap [v2] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 14:29:02 GMT, Lin Zang wrote: >> Hi @linzang, >> >> I started reviewing your patch in more detail. However, I ended up with a large number of major comments and I started >> to feel that it would probably be more productive to create an alternative patch for this, so I did. >> https://github.com/openjdk/jdk/compare/master...pliden:8252105_parallel_object_iterator >> >> Some of the main differences compared to your proposed patch: >> * Root scanning is also now done in parallel >> * Same code paths regardless of number of worker threads used >> * Arrays are chunked for better work stealing/balance >> * A terminator is used for better work stealing/balance >> * All of the functionality is isolated (as much as possible) to ZHeapIterator >> >> I think the easiest way forward is probably if you close this PR, and I'll open a new one. > > Hi @pliden, > Sorry for late reply. > I will close this PR and let's discuss in your new one. > > -Lin @linzang Ok, thanks. I created https://github.com/openjdk/jdk/pull/507. ------------- PR: https://git.openjdk.java.net/jdk/pull/103 From bobv at openjdk.java.net Mon Oct 5 19:25:45 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Mon, 5 Oct 2020 19:25:45 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> References: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> Message-ID: On Mon, 5 Oct 2020 10:16:49 GMT, Severin Gehwolf wrote: >> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd >> >> >> Note that `/proc/cgroups` looks like this: >> >> #subsys_name hierarchy num_cgroups enabled >> cpuset 0 1 1 >> cpu 0 1 1 >> cpuacct 0 1 1 >> blkio 0 1 1 >> memory 0 1 1 >> devices 0 1 1 >> freezer 0 1 1 >> net_cls 0 1 1 >> perf_event 0 1 1 >> net_prio 0 1 1 >> hugetlb 0 1 1 >> pids 0 1 1 >> >> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo >> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in >> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, >> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to >> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's >> cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and >> look for `cgroup` FS-type lines which aren't also mounted purely for systemd. >> **Testing** >> >> - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) >> - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) >> - [x] Added regression test which fails prior the patch and passes after >> - [x] Submit testing > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in comment src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 150: > 148: // find anyway in that case. > 149: try (Stream mntInfo = CgroupUtil.readFilePrivileged(Paths.get(mountInfo))) { > 150: boolean anyCgroupMounted = mntInfo.anyMatch(CgroupSubsystemFactory::noSystemdCgroupLine); I'd prefer a similar approach to the hotspot side where you do a positive check for controllers we are interested in rather than a negative check for systemd. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From david.holmes at oracle.com Tue Oct 6 01:28:02 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Oct 2020 11:28:02 +1000 Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification In-Reply-To: References: <5UPvhVjwK3TOKrd2rSzeCz-xT0tXsCUkMT9R8tgFR8I=.f1723d22-6883-4ad3-af55-a7437ef905de@github.com> Message-ID: On 5/10/2020 10:47 pm, Vladimir Kempik wrote: > On Fri, 2 Oct 2020 15:26:30 GMT, Vladimir Kempik wrote: > >>>> Okay but look at the example that documentation gives: >>>> >>>>> For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates that there is a jint parameter, the event >>>>> handler should be declared: ``` >>>>> void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) >>>>> ``` >>>> >>>> The myInt is explicit, just as our "jboolean* enabled" is explicit. I think they key point is that the signature must >>>> end with "..." which it does. >>>> I don't see anything here that needs to be fixed. >>> >>> Hello David. On majority of platforms this would be fine. >>> >>> But on some platforms, variadic arguments and non variadic arguments are passed differently ( for example on >>> macos-aarch64, variadic args are passed always on stack, non variadic on registers (and on stack for 9th+ arg) , that >>> causes issues. If you still see no issues here we can delay and make this changeset part of JEP-391. >>> But since this changeset isn't much macos-aarch64 specific, I thought it would be good to integrate it separately from >>> jep-391. >>> Regards, Vladimir >> >>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on >>> [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ >>> Hi Vladimir, >>> >>> On 2/10/2020 5:37 pm, Vladimir Kempik wrote: >>> >>>> On Fri, 2 Oct 2020 07:27:17 GMT, David Holmes wrote: >>>>> Okay but look at the example that documentation gives: >>>>>> For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates that there is a jint parameter, the event >>>>>> handler should be declared: ``` >>>>>> void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) >>>>>> ``` >>>>> >>>>> >>>>> The myInt is explicit, just as our "jboolean* enabled" is explicit. I think they key point is that the signature must >>>>> end with "..." which it does. >>>>> I don't see anything here that needs to be fixed. >>>> >>>> >>>> Hello David. On majority of platforms this would be fine. >>>> But on some platforms, variadic arguments and non variadic arguments are passed differently ( for example on >>>> macos-aarch64, variadic args are passed always on stack, non variadic on registers (and on stack for 9th+ arg) , that >>>> causes issues. >>> >>> Okay - I see the potential for a problme here but ... >>> >>>> If you still see no issues here we can delay and make this changeset part of JEP-391. >>>> But since this changeset isn't much macos-aarch64 specific, I thought it would be good to integrate it separately from >>>> jep-391. >>> >>> ... this change actually goes against the example in the spec, so if you >>> make this change it indicates the spec needs to be updated too. >>> >>> Cheers, >>> David >>> ----- >> >> Hello David >> >> I really believe the problem is in document here ( in examples) >> first, the doc clearly specify the type >> >> typedef jvmtiError (JNICALL *jvmtiExtensionFunction) >> (jvmtiEnv* jvmti_env, >> ...); >> >> then in examples it declares the function not matching this spec. >> >> Is it a good idea to update the docs in a separate bug ? >> >> Thanks, Vladimir > > Hello David > I have created CSR draft > https://bugs.openjdk.java.net/browse/JDK-8254014 Thanks. I have updated and reviewed the CSR request. David > Regards, Vladimir > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/466 > From dholmes at openjdk.java.net Tue Oct 6 02:02:45 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Oct 2020 02:02:45 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com> Message-ID: On Fri, 18 Sep 2020 10:56:56 GMT, Aleksei Voitylov wrote: >> thank you Alan, Erik, and David! When the JEP becomes Targeted, I'll use this PR to integrate the changes. > > I added the contributors that could be found in the portola project commits. If anyone knows some other contributors I > missed, I'll be happy to stand corrected. @voitylov For future reference please don't force-push commits on open PRs as it breaks the commit history. I can no longer just look at the two most recent commits and see what they added relative to what I had previously reviewed. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From dholmes at openjdk.java.net Tue Oct 6 02:28:51 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Oct 2020 02:28:51 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v10] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 11:43:52 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 16 commits: > - Review: Deal with new assert from mainline > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: StackWalker hook > - Review: Kim CR 1 and exception handling fix > - Review: Move barrier detach > - Review: Remove assert that has outstayed its welcome > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: Albert CR2 and defensive programming > - Review: StefanK CR 3 > - Review: Per CR 1 > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9604ee82...e633cb94 src/hotspot/share/runtime/safepointMechanism.cpp line 89: > 87: // > 88: // The call has been carefully placed here to cater for a few situations: > 89: // 1) After we exit from block after a global pool Typo: pool -> poll ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From dholmes at openjdk.java.net Tue Oct 6 02:42:49 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Oct 2020 02:42:49 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v10] In-Reply-To: References: Message-ID: <5ssr6WzpUH1emI5RNWd7rBRlhHkFA3EKh_yhnI-XALo=.c3537a8c-669e-44ff-8335-40cca1e36aa9@github.com> On Mon, 5 Oct 2020 11:43:52 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 16 commits: > - Review: Deal with new assert from mainline > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: StackWalker hook > - Review: Kim CR 1 and exception handling fix > - Review: Move barrier detach > - Review: Remove assert that has outstayed its welcome > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: Albert CR2 and defensive programming > - Review: StefanK CR 3 > - Review: Per CR 1 > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9604ee82...e633cb94 src/hotspot/share/runtime/stackWatermark.cpp line 223: > 221: void StackWatermark::yield_processing() { > 222: update_watermark(); > 223: MutexUnlocker mul(&_lock, Mutex::_no_safepoint_check_flag); This seems a little dubious - is it just a heuristic? There is no guarantee that unlocking the Mutex will allow another thread to claim it before this thread re-locks it. src/hotspot/share/runtime/stackWatermark.hpp line 91: > 89: JavaThread* _jt; > 90: StackWatermarkFramesIterator* _iterator; > 91: Mutex _lock; How are you guaranteeing that the Mutex is unused at the time the StackWatermark is deleted? ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From dholmes at openjdk.java.net Tue Oct 6 02:59:48 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Oct 2020 02:59:48 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v10] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 11:43:52 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 16 commits: > - Review: Deal with new assert from mainline > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: StackWalker hook > - Review: Kim CR 1 and exception handling fix > - Review: Move barrier detach > - Review: Remove assert that has outstayed its welcome > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: Albert CR2 and defensive programming > - Review: StefanK CR 3 > - Review: Per CR 1 > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9604ee82...e633cb94 src/hotspot/share/runtime/safepointMechanism.cpp line 101: > 99: uintptr_t SafepointMechanism::compute_poll_word(bool armed, uintptr_t stack_watermark) { > 100: if (armed) { > 101: log_debug(stackbarrier)("Computed armed at %d", Thread::current()->osthread()->thread_id()); s/at/for/ ? ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From dholmes at openjdk.java.net Tue Oct 6 02:59:45 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Oct 2020 02:59:45 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8] In-Reply-To: References: <4sawJHiIuc7oH5ETjrwJtJE3gkB1U2VBMVJdPmxJrg4=.e4e9b4d3-a118-4870-9b5b-f23b351093e2@github.com> Message-ID: On Thu, 1 Oct 2020 10:12:54 GMT, Erik ?sterlund wrote: >>> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on >>> [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ >>> I've only looked at scattered pieces, but what I've looked at seemed to be >>> in good shape. Only a few minor comments. >>> >>> ------------------------------------------------------------------------------ >>> src/hotspot/share/runtime/frame.cpp >>> 456 // for(StackFrameStream fst(thread); !fst.is_done(); fst.next()) { >>> >>> Needs to be updated for the new constructor arguments. Just in general, the >>> class documentation seems to need some updating for this change. >> >> Fixed. >> >>> ------------------------------------------------------------------------------ >>> src/hotspot/share/runtime/frame.cpp >>> 466 StackFrameStream(JavaThread *thread, bool update, bool process_frames); >>> >>> Something to consider is that bool parameters like that, especially when >>> there are multiple, are error prone. An alternative is distinct enums, which >>> likely also obviates the need for comments in calls. >> >> Coleen also had the same comment, and we agreed to file a follow-up RFE to clean that up. This also applies to all the >> existing parameters passed in. So I would still like to do that, but in a follow-up RFE. Said RFE will also make the >> parameter use in RegisterMap and vframeStream explicit. >>> ------------------------------------------------------------------------------ >>> src/hotspot/share/runtime/thread.hpp >>> 956 void set_processed_thread(Thread *thread) { _processed_thread = thread; } >>> >>> I think this should assert that either _processed_thread or thread are NULL. >>> Or maybe the RememberProcessedThread constructor should be asserting that >>> _cur_thr->processed_thread() is NULL. >> >> Fixed. >> >>> ------------------------------------------------------------------------------ >> >> Thanks for the review Kim! > > In my last PR update, I included a fix to an exception handling problem that I encountered after lots of stress testing > that I have been running for a while now. I managed to catch the issue, get a reliable reproducer, and fix it. > The root problem is that the hook I had placed in SharedRuntime::exception_handler_for_return_address has been ignored. > The reason is that the stack is not walkable at this point. The hook then just ignores it. This had some unexpected > consequences. After looking closer at this code, I found that if we did have a walkable stack when we call > SharedRuntime::raw_exception_handler_for_return_address, that would have been the only hook we need at all for > exception handling. It is always the common root point where we unwind into a caller frame due to an exception throwing > into the caller, and we need to look up the rethrow handler of the caller. However, we are indeed not walkable here. To > deal with this, I have rearranged the exceptino hooks a bit. First of all, I have deleted all before_unwind hooks for > exception handling, because they should not be needed if the after_unwind hook is reliably called on the caller side > instead. And those hooks do indeed need to be there, because we do not always have a point where we can call > before_unwind (e.g. C1 unwind exception code, that just unwinds and looks up the rethrow handler via > SharedRuntime::exception_handler_for_return_address). I have then traced all paths from > SharedRuntime::raw_exception_handler_for_return_address into runtime rethrow handlers called, for each rethrow > exception handler PC exposed in the function. They are: > * OptoRuntime::rethrow_C when unwinding into C2 code > * exception_handler_for_pc_helper via Runtime1::handle_exception_from_callee_id when unwinding into C1 code > * JavaCallWrapper::~JavaCallWrapper when unwinding into a Java call stub > * InterpreterRuntime::exception_handler_for_exception when unwinding into an interpreted method > * Deoptimization::fetch_unroll_info (with exec_mode == Unpack_exception) when unwinding into a deoptimized nmethod > > Each rethrow handler returned has a corresponding comment saying which rethrow runtime rethrow handler it will end up > in, once the stack has been walkable and we have transferred control into the caller. And all of those runtime hooks > now have an after_unwind() hook. The good news is that now the responsibility for who calls the unwind hook for > exception is clearer: it is never done by the callee, and always done by the caller, in its rethrow handler, at which > point the stack is walkable. In order to avoid further issues where an unwind hook is ignored, I have changed them to > assert that there is a last_Java_frame present. Previously I did not assert that, because there was shared code between > runtime native transitions and the native wrapper, that called an unwind hook. This prevented the unwind hooks to > assert this, as compiler threads would still perform native transitions, that just ignored the request. I moved the > problematic hook for native up one level in the hierarchy to a path where it is only called by native wrappers (where > we always have a last_Java_frame), so that I can finally assert that the unwind hooks always are called at points where > we have a last_Java_frame. This makes me feel confident that I do not have another hook that is being accidentally > ignored. However, the relationship for the various exception handling code executed in the caller, the callee, and > between the two (before we are walkable) is rather complicated. So it would be good to have someone that knows the > exception code very well have a look at this, to make sure I have not missed anything. I have rerun all testing and > done a load of stress testing to sanity check this. The reproducer I eventually found that reproduced the issue with > 100% success rate, was run many times with the new patch, and no longer reproduces any issue. Hi Erik, Can you give an overview of the use of the "poll word" and its relation to the "poll page" please? Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Tue Oct 6 07:22:58 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 6 Oct 2020 07:22:58 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v11] In-Reply-To: References: Message-ID: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Review: David CR 1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/296/files - new: https://git.openjdk.java.net/jdk/pull/296/files/e633cb94..2816b76b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=09-10 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Tue Oct 6 07:23:02 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 6 Oct 2020 07:23:02 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v10] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 02:26:16 GMT, David Holmes wrote: >> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 16 commits: >> - Review: Deal with new assert from mainline >> - Merge branch 'master' into 8253180_conc_stack_scanning >> - Review: StackWalker hook >> - Review: Kim CR 1 and exception handling fix >> - Review: Move barrier detach >> - Review: Remove assert that has outstayed its welcome >> - Merge branch 'master' into 8253180_conc_stack_scanning >> - Review: Albert CR2 and defensive programming >> - Review: StefanK CR 3 >> - Review: Per CR 1 >> - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9604ee82...e633cb94 > > src/hotspot/share/runtime/safepointMechanism.cpp line 89: > >> 87: // >> 88: // The call has been carefully placed here to cater for a few situations: >> 89: // 1) After we exit from block after a global pool > > Typo: pool -> poll Fixed. > src/hotspot/share/runtime/stackWatermark.cpp line 223: > >> 221: void StackWatermark::yield_processing() { >> 222: update_watermark(); >> 223: MutexUnlocker mul(&_lock, Mutex::_no_safepoint_check_flag); > > This seems a little dubious - is it just a heuristic? There is no guarantee that unlocking the Mutex will allow another > thread to claim it before this thread re-locks it. It is indeed just a heuristic. There is no need for a guarantee. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Tue Oct 6 07:26:48 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 6 Oct 2020 07:26:48 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v10] In-Reply-To: <5ssr6WzpUH1emI5RNWd7rBRlhHkFA3EKh_yhnI-XALo=.c3537a8c-669e-44ff-8335-40cca1e36aa9@github.com> References: <5ssr6WzpUH1emI5RNWd7rBRlhHkFA3EKh_yhnI-XALo=.c3537a8c-669e-44ff-8335-40cca1e36aa9@github.com> Message-ID: On Tue, 6 Oct 2020 02:40:12 GMT, David Holmes wrote: >> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 16 commits: >> - Review: Deal with new assert from mainline >> - Merge branch 'master' into 8253180_conc_stack_scanning >> - Review: StackWalker hook >> - Review: Kim CR 1 and exception handling fix >> - Review: Move barrier detach >> - Review: Remove assert that has outstayed its welcome >> - Merge branch 'master' into 8253180_conc_stack_scanning >> - Review: Albert CR2 and defensive programming >> - Review: StefanK CR 3 >> - Review: Per CR 1 >> - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9604ee82...e633cb94 > > src/hotspot/share/runtime/stackWatermark.hpp line 91: > >> 89: JavaThread* _jt; >> 90: StackWatermarkFramesIterator* _iterator; >> 91: Mutex _lock; > > How are you guaranteeing that the Mutex is unused at the time the StackWatermark is deleted? The StackWatermarks are deleted when the thread is deleted (and its destructor runs). Hence, I'm relying on the Threads SMR project here. Anyone that pokes around at the StackWatermark is either the current thread, or a thread that has a ThreadsListHandle containing the thread, making it safe to access that thread without it racingly being deleted. > src/hotspot/share/runtime/safepointMechanism.cpp line 101: > >> 99: uintptr_t SafepointMechanism::compute_poll_word(bool armed, uintptr_t stack_watermark) { >> 100: if (armed) { >> 101: log_debug(stackbarrier)("Computed armed at %d", Thread::current()->osthread()->thread_id()); > > s/at/for/ ? Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Tue Oct 6 07:37:45 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 6 Oct 2020 07:37:45 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8] In-Reply-To: References: <4sawJHiIuc7oH5ETjrwJtJE3gkB1U2VBMVJdPmxJrg4=.e4e9b4d3-a118-4870-9b5b-f23b351093e2@github.com> Message-ID: On Tue, 6 Oct 2020 02:57:00 GMT, David Holmes wrote: > Hi Erik, > Can you give an overview of the use of the "poll word" and its relation to the "poll page" please? > Thanks, > David Hi David, Thanks for reviewing this code. There are various polls in the VM. We have runtime transitions, interpreter transitions, transitions at returns, native wrappers, transitions in nmethods... and sometimes they are a bit different. The "poll word" encapsulates enough information to be able to poll for returns (stack watermark barrier), or poll for normal handshakes/safepoints, with a conditional branch. So really, we could use the "poll word" for every single poll. A low order bit is a boolean saying if handshake/safepoint is armed, and the rest of the word denotes the watermark for which frame has armed returns. The "poll page" is for polls that do not use conditional branches, but instead uses an indirect load. It is used still in nmethod loop polls, because I experimentally found it to perform worse with conditional branches on one machine, and did not want to risk regressions. It is also used for VM configurations that do not yet support stack watermark barriers, such as Graal, PPC, S390 and 32 bit platforms. They will hopefully eventually support this mechanism, but having the poll page allows a more smooth transition. And unless it is crystal clear that the performance of the conditional branch loop poll really is fast enough on sufficiently many machines, we might keep it until that changes. Hope this makes sense. Thanks, ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From sgehwolf at openjdk.java.net Tue Oct 6 08:34:42 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 6 Oct 2020 08:34:42 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: References: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> Message-ID: <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com> On Mon, 5 Oct 2020 19:22:04 GMT, Bob Vandette wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in comment > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 150: > >> 148: // find anyway in that case. >> 149: try (Stream mntInfo = CgroupUtil.readFilePrivileged(Paths.get(mountInfo))) { >> 150: boolean anyCgroupMounted = mntInfo.anyMatch(CgroupSubsystemFactory::noSystemdCgroupLine); > > I'd prefer a similar approach to the hotspot side where you do a positive check for controllers we are interested in > rather than a negative check for systemd. OK. I'll probably fold JDK-8254001 into this one then. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From aph at redhat.com Tue Oct 6 10:02:14 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Oct 2020 11:02:14 +0100 Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v11] In-Reply-To: References: Message-ID: <37965823-78b0-9cae-422f-42daf664f4fd@redhat.com> On 06/10/2020 08:22, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). One small thing: the couple of uses of lea(InternalAddress) should really be adr; this generates much better code. diff --git a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp index ce3c97d6746..119bc979e0a 100644 --- a/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp @@ -41,7 +41,7 @@ void C1SafepointPollStub::emit_code(LIR_Assembler* ce) { __ bind(_entry); InternalAddress safepoint_pc(ce->masm()->pc() - ce->masm()->offset() + safepoint_offset()); - __ lea(rscratch1, safepoint_pc); + __ adr(rscratch1, safepoint_pc); __ str(rscratch1, Address(rthread, JavaThread::saved_exception_pc_offset())); assert(SharedRuntime::polling_page_return_handler_blob() != NULL, diff --git a/src/hotspot/cpu/aarch64/c2_safepointPollStubTable_aarch64.cpp b/src/hotspot/cpu/aarch64/c2_safepointPollStubTable_aarch64.cpp index 1b627172e2d..fb36406fbde 100644 --- a/src/hotspot/cpu/aarch64/c2_safepointPollStubTable_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/c2_safepointPollStubTable_aarch64.cpp @@ -39,7 +39,7 @@ void C2SafepointPollStubTable::emit_stub_impl(MacroAssembler& masm, C2SafepointP __ bind(entry->_stub_label); InternalAddress safepoint_pc(masm.pc() - masm.offset() + entry->_safepoint_offset); - __ lea(rscratch1, safepoint_pc); + __ adr(rscratch1, safepoint_pc); __ str(rscratch1, Address(rthread, JavaThread::saved_exception_pc_offset())); __ far_jump(callback_addr); } -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rrich at openjdk.java.net Tue Oct 6 10:52:55 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Oct 2020 10:52:55 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v6] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8227745 - Merge branch 'master' into JDK-8227745 - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again. With Asynchronous handshakes the type was changed from JavaThread* to Thread* but this is not necessary as check_top_frame() is not executed during a handshake / safepoint (robehn confirmed). - Merge branch 'master' into JDK-8227745 - EATests.java: bugfix to prevent ObjectCollectedException - Better encapsulation of JvmtiDeferredUpdates. Moved jvmtiDeferredLocalVariableSet to jvmtiDeferredUpdates.hpp - EscapeBarrier: moved method comments. - Shuffled parameters of EscapeBarrier constructors to better match each other - Moved class EscapeBarrier and class JvmtiDeferredUpdates into dedicated files. - Merge branch 'master' into JDK-8227745 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/17285472...1c586cfb ------------- Changes: https://git.openjdk.java.net/jdk/pull/119/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=05 Stats: 5788 lines in 52 files changed: 5568 ins; 116 del; 104 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From eosterlund at openjdk.java.net Tue Oct 6 12:17:05 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 6 Oct 2020 12:17:05 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v12] In-Reply-To: References: Message-ID: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Review: Andrew CR 1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/296/files - new: https://git.openjdk.java.net/jdk/pull/296/files/2816b76b..54fe1f8b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=10-11 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Tue Oct 6 12:21:51 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 6 Oct 2020 12:21:51 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8] In-Reply-To: References: <4sawJHiIuc7oH5ETjrwJtJE3gkB1U2VBMVJdPmxJrg4=.e4e9b4d3-a118-4870-9b5b-f23b351093e2@github.com> Message-ID: On Tue, 6 Oct 2020 07:35:16 GMT, Erik ?sterlund wrote: >> Hi Erik, >> Can you give an overview of the use of the "poll word" and its relation to the "poll page" please? >> Thanks, >> David > >> Hi Erik, >> Can you give an overview of the use of the "poll word" and its relation to the "poll page" please? >> Thanks, >> David > > Hi David, > > Thanks for reviewing this code. > > There are various polls in the VM. We have runtime transitions, interpreter transitions, transitions at returns, native > wrappers, transitions in nmethods... and sometimes they are a bit different. > The "poll word" encapsulates enough information to be able to poll for returns (stack watermark barrier), or poll for > normal handshakes/safepoints, with a conditional branch. So really, we could use the "poll word" for every single poll. > A low order bit is a boolean saying if handshake/safepoint is armed, and the rest of the word denotes the watermark for > which frame has armed returns. The "poll page" is for polls that do not use conditional branches, but instead uses an > indirect load. It is used still in nmethod loop polls, because I experimentally found it to perform worse with > conditional branches on one machine, and did not want to risk regressions. It is also used for VM configurations that > do not yet support stack watermark barriers, such as Graal, PPC, S390 and 32 bit platforms. They will hopefully > eventually support this mechanism, but having the poll page allows a more smooth transition. And unless it is crystal > clear that the performance of the conditional branch loop poll really is fast enough on sufficiently many machines, we > might keep it until that changes. Hope this makes sense. Thanks, > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ > > On 06/10/2020 08:22, Erik ?sterlund wrote: > > > > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > > > https://openjdk.java.net/jeps/376). > > One small thing: the couple of uses of lea(InternalAddress) should really be adr; > this generates much better code. Hi Andrew, Thanks for having a look. I applied your patch. Having said that, this is run on the safepoint slow path, so should be a rather cold path, where threads have to wear coats and gloves. But it does not hurt to optimize the encoding further, I suppose. Thanks, ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From rrich at openjdk.java.net Tue Oct 6 14:09:13 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Oct 2020 14:09:13 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 13:57:26 GMT, Richard Reingruber wrote: >>> >>> >>> The minor updates in response to my comments are fine. >>> >>> The more major updates ... I can't really comment on. >> >> Thanks for looking at the changes and for giving feedback. > > Hi Serguei, > > thanks for providing feedback! I've pushed the changes based on it now but I > have not yet merged master again. This needs a little work... > > Please find my replies to your comments below. > > Thanks, Richard. > >> Could you consider to place the classes EscapeBarrier and JvmtiDeferredUpdates >> into theyr own .hpp/.cpp files? The class JvmtiDeferredUpdates would be better >> to put into the folder 'prims' then. > > Done. In addition I moved preexisting class jvmtiDeferredLocalVariableSet and > class jvmtiDeferredLocalVariable from runtime/vframe_hp.hpp to > prims/jvmtiDeferredUpdates.hpp. Please let me know if not ok. > >> src/hotspot/share/opto/macro.cpp: >> >> ``` >> @@ -1091,11 +1091,11 @@ >> bool PhaseMacroExpand::eliminate_allocate_node(AllocateNode *alloc) { >> // Don't do scalar replacement if the frame can be popped by JVMTI: >> // if reallocation fails during deoptimization we'll pop all >> // interpreter frames for this compiled frame and that won't play >> // nice with JVMTI popframe. >> - if (!EliminateAllocations || JvmtiExport::can_pop_frame() || !alloc->_is_non_escaping) { >> + if (!EliminateAllocations || !alloc->_is_non_escaping) { >> return false; >> } >> ``` >> >> I wonder if the comment is still correct after you removed the check for JvmtiExport::can_pop_frame(). > > Good catch. I fixed it previously with > https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3 > >> src/hotspot/share/runtime/deoptimization.hpp: >> >> ``` >> + EscapeBarrier(JavaThread* calling_thread, JavaThread* deoptee_thread, bool barrier_active) >> + : _calling_thread(calling_thread), _deoptee_thread(deoptee_thread), >> + _barrier_active(barrier_active && (JVMCI_ONLY(UseJVMCICompiler) NOT_JVMCI(false) >> + COMPILER2_PRESENT(|| DoEscapeAnalysis))) >> . . . . . . . . . >> + >> + // Revert ea based optimizations for all java threads >> + EscapeBarrier(JavaThread* calling_thread, bool barrier_active) >> + : _calling_thread(calling_thread), _deoptee_thread(NULL), >> ``` >> >> Nit: would better to make the parameter deoptee_thread to be the 3rd to better mach the seconf constructor. > > I have shuffled the parameters and moved barrier_active at first position. Would > that be ok? > >> >> ``` >> + bool all_threads() const { return _deoptee_thread == NULL; } // Should revert optimizations for all >> threads. + bool self_deopt() const { return _calling_thread == _deoptee_thread; } // Current thread deoptimizes >> its own objects. + bool barrier_active() const { return _barrier_active; } // Inactive barriers are >> created if no local objects can escape. ``` >> >> I'd suggest to put comments in a line before function definitions as it is done for other declarations/definitions. > > Done. // Note that there are quite a few locations with the comment on the same line ;) > >> src/hotspot/share/runtime/deoptimization.cpp: >> >> ``` >> @@ -349,12 +408,12 @@ >> >> // Now that the vframeArray has been created if we have any deferred local writes >> // added by jvmti then we can free up that structure as the data is now in the >> // vframeArray >> >> - if (thread->deferred_locals() != NULL) { >> - GrowableArray* list = thread->deferred_locals(); >> + if (JvmtiDeferredUpdates::deferred_locals(thread) != NULL) { >> + GrowableArray* list = JvmtiDeferredUpdates::deferred_locals(thread); >> int i = 0; >> do { >> // Because of inlining we could have multiple vframes for a single frame >> // and several of the vframes could have deferred writes. Find them all. >> if (list->at(i)->id() == array->original().id()) { >> >> @@ -365,13 +424,14 @@ >> } else { >> i++; >> } >> } while ( i < list->length() ); >> if (list->length() == 0) { >> - thread->set_deferred_locals(NULL); >> - // free the list and elements back to C heap. >> - delete list; >> + JvmtiDeferredUpdates* updates = thread->deferred_updates(); >> + thread->set_deferred_updates(NULL); >> + // free deferred updates. >> + delete updates; >> } >> ``` >> >> It is not clear why the 'list' is not deleted anymore. If it is intentional then could you, please, add a comment with >> an explanation? > > 'list' is now embedded in JvmtiDeferredUpdates. It es deleted as part of the > JvmtiDeferredUpdates instance when there are no more deferred updates. > > class JvmtiDeferredUpdates : public CHeapObj { > > [...] > > // Deferred updates of locals, expressions, and monitors > GrowableArray _deferred_locals_updates; > > [...] > > }; > > I introduced JvmtiDeferredUpdates because this patch introduces a new type of > deferred update: _relock_count_after_wait. > > I tried to improve the encapsulation of class JvmtiDeferredUpdates and > simplified the location you are referring to. > > So when is memory for deferred updates freed? > > (A) Deferred local variable updates are deleted when the compiled target frame is > replaced with corresponding interpreter frames. > See JvmtiDeferredUpdates::delete_updates_for_frame(). > > (B) A thread's JvmtiDeferredUpdates instance is deleted if all updates where > delivered. All updates where delivered when JvmtiDeferredUpdates::count() > returns 0. This is checked whenever updates are delivered. See call sites in > JvmtiDeferredUpdates::delete_updates_for_frame() and > JvmtiDeferredUpdates::get_and_reset_relock_count_after_wait(). > > (C) Besides (B) a thread's JvmtiDeferredUpdates instance is also deleted when > the thread is destroyed. All not yet delivered updates are deleted then > too. See JavaThread::~JavaThread() and JvmtiDeferredUpdates::~JvmtiDeferredUpdates(). > >> If you are okay to separate the EscapeBarrier class into its own hpp/cpp files >> then the class EscapeBarrierSuspendHandshake is better to be colocated with >> it. > > Done. > >> The below functions EscapeBarrier::sync_and_suspend_one() and do_thread() make a call to the set_obj_deopt_flag() which >> seems to be a duplication. At least, it is not clear why this duplication exist and so, needs to be explained in a >> comment. ``` >> +void EscapeBarrier::sync_and_suspend_one() { >> + assert(_calling_thread != NULL, "calling thread must not be NULL"); >> + assert(_deoptee_thread != NULL, "deoptee thread must not be NULL"); >> + assert(barrier_active(), "should not call"); >> + >> + // Sync with other threads that might be doing deoptimizations >> + { >> + // Need to switch to _thread_blocked for the wait() call >> + ThreadBlockInVM tbivm(_calling_thread); >> + MonitorLocker ml(_calling_thread, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag); >> + while (_self_deoptimization_in_progress || _deoptee_thread->is_obj_deopt_suspend()) { >> + ml.wait(); >> + } >> + >> + if (self_deopt()) { >> + _self_deoptimization_in_progress = true; >> + return; >> + } >> + >> + // set suspend flag for target thread >> + _deoptee_thread->set_obj_deopt_flag(); >> + } >> + >> + // suspend target thread >> + EscapeBarrierSuspendHandshake sh(NULL, "EscapeBarrierSuspendOne"); >> + Handshake::execute_direct(&sh, _deoptee_thread); >> + assert(!_deoptee_thread->has_last_Java_frame() || _deoptee_thread->frame_anchor()->walkable(), >> + "stack should be walkable now"); >> +} >> . . . . . >> +class EscapeBarrierSuspendHandshake : public HandshakeClosure { >> + JavaThread* _excluded_thread; >> + public: >> + EscapeBarrierSuspendHandshake(JavaThread* excluded_thread, const char* name) : >> + HandshakeClosure(name), >> + _excluded_thread(excluded_thread) {} >> + void do_thread(Thread* th) { >> + if (th->is_Java_thread() && !th->is_hidden_from_external_view() && (th != _excluded_thread)) { >> + th->set_obj_deopt_flag(); >> + } >> + } >> +}; >> ``` > > I previously removed the set_obj_deopt_flag() call from > EscapeBarrierSuspendHandshake::do_thread() in [1]. For synchronization it is > better to set_obj_deopt_flag() before the handshake (see comment in > EscapeBarrier::sync_and_suspend_all()). > > [1] https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3 > >> /src/hotspot/share/prims/jvmtiImpl.cpp: >> >> ``` >> 421 // Constructor for non-object getter >> 422 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type) >> 423 : _thread(thread) >> 424 , _calling_thread(NULL) >> 425 , _depth(depth) >> 426 , _index(index) >> 427 , _type(type) >> 428 , _jvf(NULL) >> 429 , _set(false) >> 430 , _eb(NULL, NULL, type == T_OBJECT) >> 431 , _result(JVMTI_ERROR_NONE) >> 432 { >> 433 } >> 434 >> 435 // Constructor for object or non-object setter >> 436 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type, jvalue value) >> 437 : _thread(thread) >> 438 , _calling_thread(NULL) >> 439 , _depth(depth) >> 440 , _index(index) >> 441 , _type(type) >> 442 , _value(value) >> 443 , _jvf(NULL) >> 444 , _set(true) >> 445 , _eb(JavaThread::current(), thread, type == T_OBJECT) >> 446 , _result(JVMTI_ERROR_NONE) >> 447 { >> 448 } >> 449 >> 450 // Constructor for object getter >> 451 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, JavaThread* calling_thread, jint depth, int index) >> 452 : _thread(thread) >> 453 , _calling_thread(calling_thread) >> 454 , _depth(depth) >> 455 , _index(index) >> 456 , _type(T_OBJECT) >> 457 , _jvf(NULL) >> 458 , _set(false) >> 459 , _eb(calling_thread, thread, true) >> 460 , _result(JVMTI_ERROR_NONE) >> 461 { >> 462 } >> ``` >> >> I think, false has to be passed to the constructors of non-object getters instead of expression: >> "type == T_OBJECT". >> The type can not be T_OBJECT for non-object getters. > > I used to do that. Then I changed it because the c++ compiler can fold the > comparison to "false" and if somebody changes the non-object getter to get > objects too then it would still be correct. > > Let me know if you still think it is better to pass false. Maybe add an > assertion type == T_OBJECT then? > >> Q: Is an EscapeBarrier useful if false is passed as the barrier_active parameter? > > The EscapeBarrier is not needed then. In the case of the non-object getter above > I'd hope that most of the constructor/desctructor of EscapeBarrier is eliminated > by the c++ compiler then. > > Besides the changes you suggested I have made a bugfix in > test/jdk/com/sun/jdi/EATests.java to prevent ObjectCollectedException. > > Thanks, Richard. Hi Serguei (@sspitsyn) are you ok with the changes I made based on your comments? Will you further review the change? Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From sspitsyn at openjdk.java.net Wed Oct 7 04:31:16 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 7 Oct 2020 04:31:16 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 14:06:35 GMT, Richard Reingruber wrote: >> Hi Serguei, >> >> thanks for providing feedback! I've pushed the changes based on it now but I >> have not yet merged master again. This needs a little work... >> >> Please find my replies to your comments below. >> >> Thanks, Richard. >> >>> Could you consider to place the classes EscapeBarrier and JvmtiDeferredUpdates >>> into theyr own .hpp/.cpp files? The class JvmtiDeferredUpdates would be better >>> to put into the folder 'prims' then. >> >> Done. In addition I moved preexisting class jvmtiDeferredLocalVariableSet and >> class jvmtiDeferredLocalVariable from runtime/vframe_hp.hpp to >> prims/jvmtiDeferredUpdates.hpp. Please let me know if not ok. >> >>> src/hotspot/share/opto/macro.cpp: >>> >>> ``` >>> @@ -1091,11 +1091,11 @@ >>> bool PhaseMacroExpand::eliminate_allocate_node(AllocateNode *alloc) { >>> // Don't do scalar replacement if the frame can be popped by JVMTI: >>> // if reallocation fails during deoptimization we'll pop all >>> // interpreter frames for this compiled frame and that won't play >>> // nice with JVMTI popframe. >>> - if (!EliminateAllocations || JvmtiExport::can_pop_frame() || !alloc->_is_non_escaping) { >>> + if (!EliminateAllocations || !alloc->_is_non_escaping) { >>> return false; >>> } >>> ``` >>> >>> I wonder if the comment is still correct after you removed the check for JvmtiExport::can_pop_frame(). >> >> Good catch. I fixed it previously with >> https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3 >> >>> src/hotspot/share/runtime/deoptimization.hpp: >>> >>> ``` >>> + EscapeBarrier(JavaThread* calling_thread, JavaThread* deoptee_thread, bool barrier_active) >>> + : _calling_thread(calling_thread), _deoptee_thread(deoptee_thread), >>> + _barrier_active(barrier_active && (JVMCI_ONLY(UseJVMCICompiler) NOT_JVMCI(false) >>> + COMPILER2_PRESENT(|| DoEscapeAnalysis))) >>> . . . . . . . . . >>> + >>> + // Revert ea based optimizations for all java threads >>> + EscapeBarrier(JavaThread* calling_thread, bool barrier_active) >>> + : _calling_thread(calling_thread), _deoptee_thread(NULL), >>> ``` >>> >>> Nit: would better to make the parameter deoptee_thread to be the 3rd to better mach the seconf constructor. >> >> I have shuffled the parameters and moved barrier_active at first position. Would >> that be ok? >> >>> >>> ``` >>> + bool all_threads() const { return _deoptee_thread == NULL; } // Should revert optimizations for all >>> threads. + bool self_deopt() const { return _calling_thread == _deoptee_thread; } // Current thread deoptimizes >>> its own objects. + bool barrier_active() const { return _barrier_active; } // Inactive barriers are >>> created if no local objects can escape. ``` >>> >>> I'd suggest to put comments in a line before function definitions as it is done for other declarations/definitions. >> >> Done. // Note that there are quite a few locations with the comment on the same line ;) >> >>> src/hotspot/share/runtime/deoptimization.cpp: >>> >>> ``` >>> @@ -349,12 +408,12 @@ >>> >>> // Now that the vframeArray has been created if we have any deferred local writes >>> // added by jvmti then we can free up that structure as the data is now in the >>> // vframeArray >>> >>> - if (thread->deferred_locals() != NULL) { >>> - GrowableArray* list = thread->deferred_locals(); >>> + if (JvmtiDeferredUpdates::deferred_locals(thread) != NULL) { >>> + GrowableArray* list = JvmtiDeferredUpdates::deferred_locals(thread); >>> int i = 0; >>> do { >>> // Because of inlining we could have multiple vframes for a single frame >>> // and several of the vframes could have deferred writes. Find them all. >>> if (list->at(i)->id() == array->original().id()) { >>> >>> @@ -365,13 +424,14 @@ >>> } else { >>> i++; >>> } >>> } while ( i < list->length() ); >>> if (list->length() == 0) { >>> - thread->set_deferred_locals(NULL); >>> - // free the list and elements back to C heap. >>> - delete list; >>> + JvmtiDeferredUpdates* updates = thread->deferred_updates(); >>> + thread->set_deferred_updates(NULL); >>> + // free deferred updates. >>> + delete updates; >>> } >>> ``` >>> >>> It is not clear why the 'list' is not deleted anymore. If it is intentional then could you, please, add a comment with >>> an explanation? >> >> 'list' is now embedded in JvmtiDeferredUpdates. It es deleted as part of the >> JvmtiDeferredUpdates instance when there are no more deferred updates. >> >> class JvmtiDeferredUpdates : public CHeapObj { >> >> [...] >> >> // Deferred updates of locals, expressions, and monitors >> GrowableArray _deferred_locals_updates; >> >> [...] >> >> }; >> >> I introduced JvmtiDeferredUpdates because this patch introduces a new type of >> deferred update: _relock_count_after_wait. >> >> I tried to improve the encapsulation of class JvmtiDeferredUpdates and >> simplified the location you are referring to. >> >> So when is memory for deferred updates freed? >> >> (A) Deferred local variable updates are deleted when the compiled target frame is >> replaced with corresponding interpreter frames. >> See JvmtiDeferredUpdates::delete_updates_for_frame(). >> >> (B) A thread's JvmtiDeferredUpdates instance is deleted if all updates where >> delivered. All updates where delivered when JvmtiDeferredUpdates::count() >> returns 0. This is checked whenever updates are delivered. See call sites in >> JvmtiDeferredUpdates::delete_updates_for_frame() and >> JvmtiDeferredUpdates::get_and_reset_relock_count_after_wait(). >> >> (C) Besides (B) a thread's JvmtiDeferredUpdates instance is also deleted when >> the thread is destroyed. All not yet delivered updates are deleted then >> too. See JavaThread::~JavaThread() and JvmtiDeferredUpdates::~JvmtiDeferredUpdates(). >> >>> If you are okay to separate the EscapeBarrier class into its own hpp/cpp files >>> then the class EscapeBarrierSuspendHandshake is better to be colocated with >>> it. >> >> Done. >> >>> The below functions EscapeBarrier::sync_and_suspend_one() and do_thread() make a call to the set_obj_deopt_flag() which >>> seems to be a duplication. At least, it is not clear why this duplication exist and so, needs to be explained in a >>> comment. ``` >>> +void EscapeBarrier::sync_and_suspend_one() { >>> + assert(_calling_thread != NULL, "calling thread must not be NULL"); >>> + assert(_deoptee_thread != NULL, "deoptee thread must not be NULL"); >>> + assert(barrier_active(), "should not call"); >>> + >>> + // Sync with other threads that might be doing deoptimizations >>> + { >>> + // Need to switch to _thread_blocked for the wait() call >>> + ThreadBlockInVM tbivm(_calling_thread); >>> + MonitorLocker ml(_calling_thread, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag); >>> + while (_self_deoptimization_in_progress || _deoptee_thread->is_obj_deopt_suspend()) { >>> + ml.wait(); >>> + } >>> + >>> + if (self_deopt()) { >>> + _self_deoptimization_in_progress = true; >>> + return; >>> + } >>> + >>> + // set suspend flag for target thread >>> + _deoptee_thread->set_obj_deopt_flag(); >>> + } >>> + >>> + // suspend target thread >>> + EscapeBarrierSuspendHandshake sh(NULL, "EscapeBarrierSuspendOne"); >>> + Handshake::execute_direct(&sh, _deoptee_thread); >>> + assert(!_deoptee_thread->has_last_Java_frame() || _deoptee_thread->frame_anchor()->walkable(), >>> + "stack should be walkable now"); >>> +} >>> . . . . . >>> +class EscapeBarrierSuspendHandshake : public HandshakeClosure { >>> + JavaThread* _excluded_thread; >>> + public: >>> + EscapeBarrierSuspendHandshake(JavaThread* excluded_thread, const char* name) : >>> + HandshakeClosure(name), >>> + _excluded_thread(excluded_thread) {} >>> + void do_thread(Thread* th) { >>> + if (th->is_Java_thread() && !th->is_hidden_from_external_view() && (th != _excluded_thread)) { >>> + th->set_obj_deopt_flag(); >>> + } >>> + } >>> +}; >>> ``` >> >> I previously removed the set_obj_deopt_flag() call from >> EscapeBarrierSuspendHandshake::do_thread() in [1]. For synchronization it is >> better to set_obj_deopt_flag() before the handshake (see comment in >> EscapeBarrier::sync_and_suspend_all()). >> >> [1] https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3 >> >>> /src/hotspot/share/prims/jvmtiImpl.cpp: >>> >>> ``` >>> 421 // Constructor for non-object getter >>> 422 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type) >>> 423 : _thread(thread) >>> 424 , _calling_thread(NULL) >>> 425 , _depth(depth) >>> 426 , _index(index) >>> 427 , _type(type) >>> 428 , _jvf(NULL) >>> 429 , _set(false) >>> 430 , _eb(NULL, NULL, type == T_OBJECT) >>> 431 , _result(JVMTI_ERROR_NONE) >>> 432 { >>> 433 } >>> 434 >>> 435 // Constructor for object or non-object setter >>> 436 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type, jvalue value) >>> 437 : _thread(thread) >>> 438 , _calling_thread(NULL) >>> 439 , _depth(depth) >>> 440 , _index(index) >>> 441 , _type(type) >>> 442 , _value(value) >>> 443 , _jvf(NULL) >>> 444 , _set(true) >>> 445 , _eb(JavaThread::current(), thread, type == T_OBJECT) >>> 446 , _result(JVMTI_ERROR_NONE) >>> 447 { >>> 448 } >>> 449 >>> 450 // Constructor for object getter >>> 451 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, JavaThread* calling_thread, jint depth, int index) >>> 452 : _thread(thread) >>> 453 , _calling_thread(calling_thread) >>> 454 , _depth(depth) >>> 455 , _index(index) >>> 456 , _type(T_OBJECT) >>> 457 , _jvf(NULL) >>> 458 , _set(false) >>> 459 , _eb(calling_thread, thread, true) >>> 460 , _result(JVMTI_ERROR_NONE) >>> 461 { >>> 462 } >>> ``` >>> >>> I think, false has to be passed to the constructors of non-object getters instead of expression: >>> "type == T_OBJECT". >>> The type can not be T_OBJECT for non-object getters. >> >> I used to do that. Then I changed it because the c++ compiler can fold the >> comparison to "false" and if somebody changes the non-object getter to get >> objects too then it would still be correct. >> >> Let me know if you still think it is better to pass false. Maybe add an >> assertion type == T_OBJECT then? >> >>> Q: Is an EscapeBarrier useful if false is passed as the barrier_active parameter? >> >> The EscapeBarrier is not needed then. In the case of the non-object getter above >> I'd hope that most of the constructor/desctructor of EscapeBarrier is eliminated >> by the c++ compiler then. >> >> Besides the changes you suggested I have made a bugfix in >> test/jdk/com/sun/jdi/EATests.java to prevent ObjectCollectedException. >> >> Thanks, Richard. > > Hi Serguei > (@sspitsyn) > > are you ok with the changes I made based on your comments? > Will you further review the change? > > Thanks, Richard. Hi Richard, Thank you for making the refactoring. I like it more now. :) So, the fix looks good to me in general. But could I ask you, to adjust some formatting, please? There are several things that can be done to improve the code readability. src/hotspot/share/prims/jvmtiDeferredUpdates.hpp: I'd suggest to add an empty line before lines 40, 71, 73, 93, 95, 109 to make class definitions and function declarations/definitions with comments more catchable by eyes. The following lines can be removed: 81, 82, 103 Also, there is inconsistency in function definitions formatting: - some functions have big indent between the type and name - some functions have no indent between the type and name but a big indent between name and body I'd suggest to either to remove all indents or make it reasonably smaller but consistent. It seems, there is no reason to keep these class declarations: 38 class jvmtiDeferredLocalVariable; 108 class jvmtiDeferredLocalVariableSet; src/hotspot/share/prims/jvmtiDeferredUpdates.cpp: 82 // Free deferred updates. 83 // (Note the 'list' of local variable updates is embedded in 'updates') A suggestion to change the line 83 as follows: ` 83 // Note, the 'list' of local variable updates is embedded in 'updates'.` src/hotspot/share/runtime/escapeBarrier.hpp: Add dots at the end of comments at lines 97, 99, 103. I'd suggest to add an empty line before lines 39, 40, 80, 81, 93, 94, 99, 119, 121. src/hotspot/share/runtime/escapeBarrier.cpp: The following class declaration is not needed: ` 49 class jvmtiDeferredLocalVariableSet;` because you already added this line: ` 29 #include "prims/jvmtiDeferredUpdates.hpp"` The lines below deserve a refactoring. It can be separate functions for locals, expressions and monitors, or just one function for the whole fragment: 345 GrowableArray* scopeLocals = cvf->scope()->locals(); 346 StackValueCollection* locals = cvf->locals(); 347 if (locals != NULL) { 348 for (int i2 = 0; i2 < locals->size(); i2++) { 349 StackValue* var = locals->at(i2); 350 if (var->type() == T_OBJECT && scopeLocals->at(i2)->is_object()) { 351 jvalue val; 352 val.l = cast_from_oop(locals->at(i2)->get_obj()()); 353 cvf->update_local(T_OBJECT, i2, val); 354 } 355 } 356 } 357 358 // expressions 359 GrowableArray* scopeExpressions = cvf->scope()->expressions(); 360 StackValueCollection* expressions = cvf->expressions(); 361 if (expressions != NULL) { 362 for (int i2 = 0; i2 < expressions->size(); i2++) { 363 StackValue* var = expressions->at(i2); 364 if (var->type() == T_OBJECT && scopeExpressions->at(i2)->is_object()) { 365 jvalue val; 366 val.l = cast_from_oop(expressions->at(i2)->get_obj()()); 367 cvf->update_stack(T_OBJECT, i2, val); 368 } 369 } 370 } 371 372 // monitors 373 GrowableArray* monitors = cvf->monitors(); 374 if (monitors != NULL) { 375 for (int i2 = 0; i2 < monitors->length(); i2++) { 376 if (monitors->at(i2)->eliminated()) { 377 assert(!monitors->at(i2)->owner_is_scalar_replaced(), 378 "reallocation failure, should not update"); 379 cvf->update_monitor(i2, monitors->at(i2)); 380 } 381 } 382 } src/hotspot/share/prims/jvmtiImpl.cpp: 420 // Constructor for non-object getter 421 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type) 422 : _thread(thread) 423 , _calling_thread(NULL) 424 , _depth(depth) 425 , _index(index) 426 , _type(type) 427 , _jvf(NULL) 428 , _set(false) 429 , _eb(type == T_OBJECT, NULL, NULL) 430 , _result(JVMTI_ERROR_NONE) 431 { 432 } I still think, that the line 429 is going to cause confusions. It is a non-object getter, so the type should never be T_OBJECT. It won't change in the future to allow the T_OBJECT types. The only way to allow it is to merge the constructors for object and non-object getters. So, I'm suggesting to replace this line with: ` 429 , _eb(false, NULL, NULL)` ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From david.holmes at oracle.com Wed Oct 7 06:39:57 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Oct 2020 16:39:57 +1000 Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8] In-Reply-To: References: <4sawJHiIuc7oH5ETjrwJtJE3gkB1U2VBMVJdPmxJrg4=.e4e9b4d3-a118-4870-9b5b-f23b351093e2@github.com> Message-ID: Hi Erik, On 6/10/2020 5:37 pm, Erik ?sterlund wrote: > On Tue, 6 Oct 2020 02:57:00 GMT, David Holmes wrote: > >> Hi Erik, >> Can you give an overview of the use of the "poll word" and its relation to the "poll page" please? >> Thanks, >> David > > Hi David, > > Thanks for reviewing this code. > > There are various polls in the VM. We have runtime transitions, interpreter transitions, transitions at returns, native > wrappers, transitions in nmethods... and sometimes they are a bit different. > > The "poll word" encapsulates enough information to be able to poll for returns (stack watermark barrier), or poll for > normal handshakes/safepoints, with a conditional branch. So really, we could use the "poll word" for every single poll. > A low order bit is a boolean saying if handshake/safepoint is armed, and the rest of the word denotes the watermark for > which frame has armed returns. > > The "poll page" is for polls that do not use conditional branches, but instead uses an indirect load. It is used still > in nmethod loop polls, because I experimentally found it to perform worse with conditional branches on one machine, and > did not want to risk regressions. It is also used for VM configurations that do not yet support stack watermark > barriers, such as Graal, PPC, S390 and 32 bit platforms. They will hopefully eventually support this mechanism, but > having the poll page allows a more smooth transition. And unless it is crystal clear that the performance of the > conditional branch loop poll really is fast enough on sufficiently many machines, we might keep it until that changes. > > Hope this makes sense. Yes but I am somewhat surprised. The conventional wisdom has always been that polling based on the "poison page" approach far outperforms explicit load-test-branch approaches. Cheers, David > Thanks, > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/296 > From eosterlund at openjdk.java.net Wed Oct 7 07:00:15 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 7 Oct 2020 07:00:15 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8] In-Reply-To: References: <4sawJHiIuc7oH5ETjrwJtJE3gkB1U2VBMVJdPmxJrg4=.e4e9b4d3-a118-4870-9b5b-f23b351093e2@github.com> Message-ID: On Tue, 6 Oct 2020 12:18:39 GMT, Erik ?sterlund wrote: >>> Hi Erik, >>> Can you give an overview of the use of the "poll word" and its relation to the "poll page" please? >>> Thanks, >>> David >> >> Hi David, >> >> Thanks for reviewing this code. >> >> There are various polls in the VM. We have runtime transitions, interpreter transitions, transitions at returns, native >> wrappers, transitions in nmethods... and sometimes they are a bit different. >> The "poll word" encapsulates enough information to be able to poll for returns (stack watermark barrier), or poll for >> normal handshakes/safepoints, with a conditional branch. So really, we could use the "poll word" for every single poll. >> A low order bit is a boolean saying if handshake/safepoint is armed, and the rest of the word denotes the watermark for >> which frame has armed returns. The "poll page" is for polls that do not use conditional branches, but instead uses an >> indirect load. It is used still in nmethod loop polls, because I experimentally found it to perform worse with >> conditional branches on one machine, and did not want to risk regressions. It is also used for VM configurations that >> do not yet support stack watermark barriers, such as Graal, PPC, S390 and 32 bit platforms. They will hopefully >> eventually support this mechanism, but having the poll page allows a more smooth transition. And unless it is crystal >> clear that the performance of the conditional branch loop poll really is fast enough on sufficiently many machines, we >> might keep it until that changes. Hope this makes sense. Thanks, > >> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ >> >> On 06/10/2020 08:22, Erik ?sterlund wrote: >> >> > > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> > > https://openjdk.java.net/jeps/376). >> >> One small thing: the couple of uses of lea(InternalAddress) should really be adr; >> this generates much better code. > > Hi Andrew, > > Thanks for having a look. I applied your patch. Having said that, this is run on the safepoint slow path, so should be > a rather cold path, where threads have to wear coats and gloves. But it does not hurt to optimize the encoding further, > I suppose. Thanks, > > *Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on > [serviceability-dev](mailto:serviceability-dev at openjdk.java.net):* > > Hi Erik, > > On 6/10/2020 5:37 pm, Erik ?sterlund wrote: > > On Tue, 6 Oct 2020 02:57:00 GMT, David Holmes wrote: > > > >> Hi Erik, > >> Can you give an overview of the use of the "poll word" and its relation to the "poll page" please? > >> Thanks, > >> David > > > > Hi David, > > > > Thanks for reviewing this code. > > > > There are various polls in the VM. We have runtime transitions, interpreter transitions, transitions at returns, native > > wrappers, transitions in nmethods... and sometimes they are a bit different. > > > > The "poll word" encapsulates enough information to be able to poll for returns (stack watermark barrier), or poll for > > normal handshakes/safepoints, with a conditional branch. So really, we could use the "poll word" for every single poll. > > A low order bit is a boolean saying if handshake/safepoint is armed, and the rest of the word denotes the watermark for > > which frame has armed returns. > > > > The "poll page" is for polls that do not use conditional branches, but instead uses an indirect load. It is used still > > in nmethod loop polls, because I experimentally found it to perform worse with conditional branches on one machine, and > > did not want to risk regressions. It is also used for VM configurations that do not yet support stack watermark > > barriers, such as Graal, PPC, S390 and 32 bit platforms. They will hopefully eventually support this mechanism, but > > having the poll page allows a more smooth transition. And unless it is crystal clear that the performance of the > > conditional branch loop poll really is fast enough on sufficiently many machines, we might keep it until that changes. > > > > Hope this makes sense. > > Yes but I am somewhat surprised. The conventional wisdom has always been > that polling based on the "poison page" approach far outperforms > explicit load-test-branch approaches. > > Cheers, > David When thread local handshakes was built, both a branch based and indirect load based prototype was implemented. I had a branch based solution and Mikael Gerdin built an indirect load based solution, so we could compare them. He compared them on many machines and found that sometimes branches are a bit faster and sometimes a bit slower, depending on CPU model. But the results with indirect loads was more stable from machine to machine, while the branch based solution depended a bit more on what CPU model was being used. That is why the indirect load solution was chosen: it was not always best but it was never bad on any machine. Since then, we got loop strip mining in C2 which makes the frequency of polls less tight. My hypothesis was that with that in place, a new evaluation would show that branching is fine now. However, one machine did not agree with that. To be fair, that machine is not giving very stable results at all right now, so I am not sure if there is a real problem or not. But I thought I'll keep the old behaviour for now anyway as I do not yet have a good reason to change it, and not good enough proof that it is okay... yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From afarley at openjdk.java.net Wed Oct 7 08:08:15 2020 From: afarley at openjdk.java.net (Adam Farley) Date: Wed, 7 Oct 2020 08:08:15 GMT Subject: Integrated: 8252997: Null-proofing for linker_md.c In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 11:09:19 GMT, Adam Farley wrote: > In the platform-specific implementations of linker_md.c, we see the dll_build_name methods begin with a call to > jvmtiAllocate. > We then appear to rush ahead and try to use that variable without checking for a null. > > I propose moving the null check to the point *before* we try to use that variable, to avoid any possible SEGV. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8252997 This pull request has now been integrated. Changeset: 4dfa4112 Author: Adam Farley Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/4dfa4112 Stats: 8 lines in 2 files changed: 4 ins; 2 del; 2 mod 8252997: Null-proofing for linker_md.c Reviewed-by: sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/246 From sgehwolf at openjdk.java.net Wed Oct 7 08:11:25 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 7 Oct 2020 08:11:25 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v4] In-Reply-To: References: Message-ID: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and > look for `cgroup` FS-type lines which aren't also mounted purely for systemd. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/d334ac60..5e2ca2dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=02-03 Stats: 548 lines in 5 files changed: 284 ins; 193 del; 71 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Wed Oct 7 08:11:25 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 7 Oct 2020 08:11:25 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com> References: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com> Message-ID: On Tue, 6 Oct 2020 08:32:25 GMT, Severin Gehwolf wrote: >> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 150: >> >>> 148: // find anyway in that case. >>> 149: try (Stream mntInfo = CgroupUtil.readFilePrivileged(Paths.get(mountInfo))) { >>> 150: boolean anyCgroupMounted = mntInfo.anyMatch(CgroupSubsystemFactory::noSystemdCgroupLine); >> >> I'd prefer a similar approach to the hotspot side where you do a positive check for controllers we are interested in >> rather than a negative check for systemd. > > OK. I'll probably fold JDK-8254001 into this one then. @bobvandette Done in the latest version. Thoughts? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Wed Oct 7 08:11:26 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 7 Oct 2020 08:11:26 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v4] In-Reply-To: References: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> Message-ID: On Mon, 5 Oct 2020 08:59:34 GMT, Severin Gehwolf wrote: >> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 80: >> >>> 78: */ >>> 79: private static final Pattern MOUNTINFO_PATTERN = >>> 80: >>> Pattern.compile("^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+([^\\s]+)\\s+([^\\s]+)\\s+[^-]+-\\s+([^\\s]+)\\s+.*$"); >> >> Only group_3 = fstype is used in the pattern, right? > > Yes. I've removed unused groups now, though. > > Originally, my thinking was that `mount root` and `mount path` would be useful too so I kept it in. It would certainly > be useful for getting rid of reading `/proc/self/mountinfo` twice on the Java side. As a future enhancement we could do > away with double parsing of mount info by keeping track of relevant cgroup controller info. I've filed > [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) to track this. The latest version goes back to using all three as it's beneficial to track that info and use it later on for instantiating the version specific objects. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From bulasevich at openjdk.java.net Wed Oct 7 11:59:14 2020 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Wed, 7 Oct 2020 11:59:14 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v4] In-Reply-To: References: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> Message-ID: On Wed, 7 Oct 2020 08:08:13 GMT, Severin Gehwolf wrote: >> Yes. I've removed unused groups now, though. >> >> Originally, my thinking was that `mount root` and `mount path` would be useful too so I kept it in. It would certainly >> be useful for getting rid of reading `/proc/self/mountinfo` twice on the Java side. As a future enhancement we could do >> away with double parsing of mount info by keeping track of relevant cgroup controller info. I've filed >> [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) to track this. > > The latest version goes back to using all three as it's beneficial to track that info and use it later on for > instantiating the version specific objects. ok! ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From vromero at openjdk.java.net Wed Oct 7 13:36:29 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 7 Oct 2020 13:36:29 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v10] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implementing Record Classes as a standard feature in Java Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing unused jcod file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/7501148d..1bcda595 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=08-09 Stats: 256 lines in 1 file changed: 0 ins; 256 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From rrich at openjdk.java.net Wed Oct 7 17:52:27 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 7 Oct 2020 17:52:27 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v7] In-Reply-To: References: Message-ID: <6Scp6XjVCcdJN0tUKionVwGKoiBG8UeA-OpBXHrCYqk=.01170b1e-9722-4461-84e4-77e8fd447ac4@github.com> > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request incrementally with five additional commits since the last revision: - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame. - More smaller changes proposed by Serguei. - jvmtiDeferredUpdates.hpp: remove forward declarations. - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition. - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/119/files - new: https://git.openjdk.java.net/jdk/pull/119/files/1c586cfb..03f751eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=05-06 Stats: 183 lines in 7 files changed: 93 ins; 66 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Wed Oct 7 17:55:11 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 7 Oct 2020 17:55:11 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3] In-Reply-To: References: Message-ID: On Wed, 7 Oct 2020 04:28:16 GMT, Serguei Spitsyn wrote: >> Hi Serguei >> (@sspitsyn) >> >> are you ok with the changes I made based on your comments? >> Will you further review the change? >> >> Thanks, Richard. > > Hi Richard, > > Thank you for making the refactoring. I like it more now. :) > So, the fix looks good to me in general. > > But could I ask you, to adjust some formatting, please? > There are several things that can be done to improve the code readability. > > src/hotspot/share/prims/jvmtiDeferredUpdates.hpp: > > I'd suggest to add an empty line before lines 40, 71, 73, 93, 95, 109 to make class definitions and function > declarations/definitions with comments more catchable by eyes. The following lines can be removed: 81, 82, 103 > > Also, there is inconsistency in function definitions formatting: > - some functions have big indent between the type and name > - some functions have no indent between the type and name but a big indent between name and body > I'd suggest to either to remove all indents or make it reasonably smaller but consistent. > > It seems, there is no reason to keep these class declarations: > 38 class jvmtiDeferredLocalVariable; > 108 class jvmtiDeferredLocalVariableSet; > > src/hotspot/share/prims/jvmtiDeferredUpdates.cpp: > > 82 // Free deferred updates. > 83 // (Note the 'list' of local variable updates is embedded in 'updates') > > A suggestion to change the line 83 as follows: > ` 83 // Note, the 'list' of local variable updates is embedded in 'updates'.` > > src/hotspot/share/runtime/escapeBarrier.hpp: > > Add dots at the end of comments at lines 97, 99, 103. > I'd suggest to add an empty line before lines 39, 40, 80, 81, 93, 94, 99, 119, 121. > > src/hotspot/share/runtime/escapeBarrier.cpp: > > The following class declaration is not needed: > ` 49 class jvmtiDeferredLocalVariableSet;` > > because you already added this line: > ` 29 #include "prims/jvmtiDeferredUpdates.hpp"` > > The lines below deserve a refactoring. It can be separate functions for locals, expressions and monitors, or just one > function for the whole fragment: > 345 GrowableArray* scopeLocals = cvf->scope()->locals(); > 346 StackValueCollection* locals = cvf->locals(); > 347 if (locals != NULL) { > 348 for (int i2 = 0; i2 < locals->size(); i2++) { > 349 StackValue* var = locals->at(i2); > 350 if (var->type() == T_OBJECT && scopeLocals->at(i2)->is_object()) { > 351 jvalue val; > 352 val.l = cast_from_oop(locals->at(i2)->get_obj()()); > 353 cvf->update_local(T_OBJECT, i2, val); > 354 } > 355 } > 356 } > 357 > 358 // expressions > 359 GrowableArray* scopeExpressions = cvf->scope()->expressions(); > 360 StackValueCollection* expressions = cvf->expressions(); > 361 if (expressions != NULL) { > 362 for (int i2 = 0; i2 < expressions->size(); i2++) { > 363 StackValue* var = expressions->at(i2); > 364 if (var->type() == T_OBJECT && scopeExpressions->at(i2)->is_object()) { > 365 jvalue val; > 366 val.l = cast_from_oop(expressions->at(i2)->get_obj()()); > 367 cvf->update_stack(T_OBJECT, i2, val); > 368 } > 369 } > 370 } > 371 > 372 // monitors > 373 GrowableArray* monitors = cvf->monitors(); > 374 if (monitors != NULL) { > 375 for (int i2 = 0; i2 < monitors->length(); i2++) { > 376 if (monitors->at(i2)->eliminated()) { > 377 assert(!monitors->at(i2)->owner_is_scalar_replaced(), > 378 "reallocation failure, should not update"); > 379 cvf->update_monitor(i2, monitors->at(i2)); > 380 } > 381 } > 382 } > > > src/hotspot/share/prims/jvmtiImpl.cpp: > > 420 // Constructor for non-object getter > 421 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type) > 422 : _thread(thread) > 423 , _calling_thread(NULL) > 424 , _depth(depth) > 425 , _index(index) > 426 , _type(type) > 427 , _jvf(NULL) > 428 , _set(false) > 429 , _eb(type == T_OBJECT, NULL, NULL) > 430 , _result(JVMTI_ERROR_NONE) > 431 { > 432 } > > I still think, that the line 429 is going to cause confusions. > It is a non-object getter, so the type should never be T_OBJECT. > It won't change in the future to allow the T_OBJECT types. > The only way to allow it is to merge the constructors for object and non-object getters. > So, I'm suggesting to replace this line with: > ` 429 , _eb(false, NULL, NULL)` Hi Serguei, > Thank you for making the refactoring. I like it more now. :) > So, the fix looks good to me in general. Good :) > But could I ask you, to adjust some formatting, please? > There are several things that can be done to improve the code readability. > > src/hotspot/share/prims/jvmtiDeferredUpdates.hpp: > > I'd suggest to add an empty line before lines 40, 71, 73, 93, 95, 109 to make class definitions and function > declarations/definitions with comments more catchable by eyes. The following lines can be removed: 81, 82, 103 Sure. I've made the changes. > Also, there is inconsistency in function definitions formatting: > > * some functions have big indent between the type and name > > * some functions have no indent between the type and name but a big indent between name and body > I'd suggest to either to remove all indents or make it reasonably smaller but consistent. > I've made the indents smaller. I also moved private members jvmtiDeferredLocalVariable at the beginning. Looks better now. > It seems, there is no reason to keep these class declarations: > > ``` > 38 class jvmtiDeferredLocalVariable; > 108 class jvmtiDeferredLocalVariableSet; > ``` Removed. > src/hotspot/share/prims/jvmtiDeferredUpdates.cpp: > > ``` > 82 // Free deferred updates. > 83 // (Note the 'list' of local variable updates is embedded in 'updates') > ``` > > A suggestion to change the line 83 as follows: > ` 83 // Note, the 'list' of local variable updates is embedded in 'updates'.` Done. > src/hotspot/share/runtime/escapeBarrier.hpp: > > Add dots at the end of comments at lines 97, 99, 103. > I'd suggest to add an empty line before lines 39, 40, 80, 81, 93, 94, 99, 119, 121. Done. > src/hotspot/share/runtime/escapeBarrier.cpp: > > The following class declaration is not needed: > ` 49 class jvmtiDeferredLocalVariableSet;` > > because you already added this line: > ` 29 #include "prims/jvmtiDeferredUpdates.hpp"` Your right. Thanks. > The lines below deserve a refactoring. It can be separate functions for locals, expressions and monitors, or just one > function for the whole fragment: > ``` > 345 GrowableArray* scopeLocals = cvf->scope()->locals(); > 346 StackValueCollection* locals = cvf->locals(); > 347 if (locals != NULL) { > 348 for (int i2 = 0; i2 < locals->size(); i2++) { > 349 StackValue* var = locals->at(i2); > 350 if (var->type() == T_OBJECT && scopeLocals->at(i2)->is_object()) { > 351 jvalue val; > 352 val.l = cast_from_oop(locals->at(i2)->get_obj()()); > 353 cvf->update_local(T_OBJECT, i2, val); > 354 } > 355 } > 356 } > 357 > 358 // expressions > 359 GrowableArray* scopeExpressions = cvf->scope()->expressions(); > 360 StackValueCollection* expressions = cvf->expressions(); > 361 if (expressions != NULL) { > 362 for (int i2 = 0; i2 < expressions->size(); i2++) { > 363 StackValue* var = expressions->at(i2); > 364 if (var->type() == T_OBJECT && scopeExpressions->at(i2)->is_object()) { > 365 jvalue val; > 366 val.l = cast_from_oop(expressions->at(i2)->get_obj()()); > 367 cvf->update_stack(T_OBJECT, i2, val); > 368 } > 369 } > 370 } > 371 > 372 // monitors > 373 GrowableArray* monitors = cvf->monitors(); > 374 if (monitors != NULL) { > 375 for (int i2 = 0; i2 < monitors->length(); i2++) { > 376 if (monitors->at(i2)->eliminated()) { > 377 assert(!monitors->at(i2)->owner_is_scalar_replaced(), > 378 "reallocation failure, should not update"); > 379 cvf->update_monitor(i2, monitors->at(i2)); > 380 } > 381 } > 382 } > ``` I moved the fragment into a new method in compiledVFrame. Please note that an equal fragment exists here too: https://github.com/openjdk/jdk/blob/1e8e543b264bb985bfee535fedc9ffe7db5ad482/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#L1524-L1558 Actually this location could be implemented on top of EscapeBarrier. Maybe (maybe not?) in a follow-up... > src/hotspot/share/prims/jvmtiImpl.cpp: > > ``` > 420 // Constructor for non-object getter > 421 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type) > 422 : _thread(thread) > 423 , _calling_thread(NULL) > 424 , _depth(depth) > 425 , _index(index) > 426 , _type(type) > 427 , _jvf(NULL) > 428 , _set(false) > 429 , _eb(type == T_OBJECT, NULL, NULL) > 430 , _result(JVMTI_ERROR_NONE) > 431 { > 432 } > ``` > > I still think, that the line 429 is going to cause confusions. > It is a non-object getter, so the type should never be T_OBJECT. > It won't change in the future to allow the T_OBJECT types. > The only way to allow it is to merge the constructors for object and non-object getters. > So, I'm suggesting to replace this line with: > ` 429 , _eb(false, NULL, NULL)` Ok, done. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From smonteith at openjdk.java.net Wed Oct 7 18:06:15 2020 From: smonteith at openjdk.java.net (Stuart Monteith) Date: Wed, 7 Oct 2020 18:06:15 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v12] In-Reply-To: References: Message-ID: <19ts4LYwyvtljcsVAjrinz6Jx2esPUWeUdByyX0CUUo=.2b78dff1-8d73-453e-95f5-4362cc3635f3@github.com> On Tue, 6 Oct 2020 12:17:05 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Review: Andrew CR 1 I've been reviewing this and stepping through the debugger. It looks OK to me. ------------- Marked as reviewed by smonteith (Author). PR: https://git.openjdk.java.net/jdk/pull/296 From bobv at openjdk.java.net Wed Oct 7 19:09:08 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Wed, 7 Oct 2020 19:09:08 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: References: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com> Message-ID: <-Ghp9lTLaabHLOEnriSryHKOCx-cgIcS1sE4B8tmrm0=.4becaccc-6cb0-480b-b975-540d24f9949c@github.com> On Wed, 7 Oct 2020 08:06:58 GMT, Severin Gehwolf wrote: >> OK. I'll probably fold JDK-8254001 into this one then. > > @bobvandette Done in the latest version. Thoughts? I'm a little uncomfortable making such a dramatic change just to fix this small isolated problem. I think about all the churn we've had on these files and the backports to come. Could you just add a CgroupSubsystemFactory::isValidSubsystem function which checks for cpuset, cpuacct, memory, etc instead of the major change? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Wed Oct 7 19:34:12 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 7 Oct 2020 19:34:12 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: <-Ghp9lTLaabHLOEnriSryHKOCx-cgIcS1sE4B8tmrm0=.4becaccc-6cb0-480b-b975-540d24f9949c@github.com> References: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com> <-Ghp9lTLaabHLOEnriSryHKOCx-cgIcS1sE4B8tmrm0=.4becaccc-6cb0-480b-b975-540d24f9949c@github.com> Message-ID: On Wed, 7 Oct 2020 19:05:57 GMT, Bob Vandette wrote: >> @bobvandette Done in the latest version. Thoughts? > > I'm a little uncomfortable making such a dramatic change just to fix this small isolated problem. I think about all > the churn we've had on these files and the backports to come. Could you just add a > CgroupSubsystemFactory::isValidSubsystem function which checks for cpuset, cpuacct, memory, etc instead of the major > change? Thanks for having a look! Sure, we could do that instead. I'm not sure this is the best solution going forward, though. Thinking about JDK 17... Anyway, I'll look into a more conservative fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sspitsyn at openjdk.java.net Wed Oct 7 19:50:11 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 7 Oct 2020 19:50:11 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v7] In-Reply-To: <6Scp6XjVCcdJN0tUKionVwGKoiBG8UeA-OpBXHrCYqk=.01170b1e-9722-4461-84e4-77e8fd447ac4@github.com> References: <6Scp6XjVCcdJN0tUKionVwGKoiBG8UeA-OpBXHrCYqk=.01170b1e-9722-4461-84e4-77e8fd447ac4@github.com> Message-ID: On Wed, 7 Oct 2020 17:52:27 GMT, Richard Reingruber wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > Richard Reingruber has updated the pull request incrementally with five additional commits since the last revision: > > - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame. > - More smaller changes proposed by Serguei. > - jvmtiDeferredUpdates.hpp: remove forward declarations. > - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition. > - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation. Richard, Thank you for the formatting and refactoring changes. The fix looks good to me. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/119 From eosterlund at openjdk.java.net Thu Oct 8 07:00:16 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 8 Oct 2020 07:00:16 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v12] In-Reply-To: <19ts4LYwyvtljcsVAjrinz6Jx2esPUWeUdByyX0CUUo=.2b78dff1-8d73-453e-95f5-4362cc3635f3@github.com> References: <19ts4LYwyvtljcsVAjrinz6Jx2esPUWeUdByyX0CUUo=.2b78dff1-8d73-453e-95f5-4362cc3635f3@github.com> Message-ID: On Wed, 7 Oct 2020 18:03:10 GMT, Stuart Monteith wrote: > I've been reviewing this and stepping through the debugger. It looks OK to me. Thanks for the review Stuart. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From amenkov at openjdk.java.net Thu Oct 8 07:03:45 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 8 Oct 2020 07:03:45 GMT Subject: RFR: 8249623: test @ignore-d due to 7013634 should be returned back to =?UTF-8?B?ZXhl4oCm?= Message-ID: - updated timeout/stressTime for resexhausted001 test so on Windows we get "can't reproduce OOME" instead of timeout; - updated resexhausted001 cleanup code (to terminate all threads); - intermittent resexhausted001 failure on linux is problem-listed; - updated resexhausted001 and resexhausted002 to throw SkippedException if OOM is not thrown ------------- Commit messages: - 8249623: test @ignore-d due to 7013634 should be returned back to execution Changes: https://git.openjdk.java.net/jdk/pull/551/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=551&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249623 Stats: 12 lines in 4 files changed: 4 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/551.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/551/head:pull/551 PR: https://git.openjdk.java.net/jdk/pull/551 From rrich at openjdk.java.net Thu Oct 8 08:54:59 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 8 Oct 2020 08:54:59 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v8] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge branch 'master' into JDK-8227745 - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame. - More smaller changes proposed by Serguei. - jvmtiDeferredUpdates.hpp: remove forward declarations. - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition. - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation. - Merge branch 'master' into JDK-8227745 - Merge branch 'master' into JDK-8227745 - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again. With Asynchronous handshakes the type was changed from JavaThread* to Thread* but this is not necessary as check_top_frame() is not executed during a handshake / safepoint (robehn confirmed). - Merge branch 'master' into JDK-8227745 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/8f9e4792...94c89691 ------------- Changes: https://git.openjdk.java.net/jdk/pull/119/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=07 Stats: 5815 lines in 52 files changed: 5595 ins; 116 del; 104 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Thu Oct 8 08:55:00 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 8 Oct 2020 08:55:00 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v7] In-Reply-To: References: <6Scp6XjVCcdJN0tUKionVwGKoiBG8UeA-OpBXHrCYqk=.01170b1e-9722-4461-84e4-77e8fd447ac4@github.com> Message-ID: On Wed, 7 Oct 2020 19:47:07 GMT, Serguei Spitsyn wrote: > > > Richard, > Thank you for the formatting and refactoring changes. > The fix looks good to me. Thank you very much Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Thu Oct 8 09:13:45 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 8 Oct 2020 09:13:45 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v7] In-Reply-To: References: <6Scp6XjVCcdJN0tUKionVwGKoiBG8UeA-OpBXHrCYqk=.01170b1e-9722-4461-84e4-77e8fd447ac4@github.com> Message-ID: On Thu, 8 Oct 2020 08:50:08 GMT, Richard Reingruber wrote: >> Richard, >> Thank you for the formatting and refactoring changes. >> The fix looks good to me. > >> >> >> Richard, >> Thank you for the formatting and refactoring changes. >> The fix looks good to me. > > Thank you very much Serguei! I'm planning to integrate this pull request on Monday 2020-10-12. There was one failing test on Windows x64: [tools/javac/launcher/SourceLauncherTest.java](https://github.com/reinrich/jdk/runs/1222200722). This was most likely caused by [JDK-8249095](https://bugs.openjdk.java.net/browse/JDK-8249095). I've merged master to verify this. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From avoitylov at openjdk.java.net Thu Oct 8 10:52:53 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Thu, 8 Oct 2020 10:52:53 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v6] In-Reply-To: References: Message-ID: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. Aleksei Voitylov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into JDK-8247589 - JDK-8247589: Implementation of Alpine Linux/x64 Port - JDK-8247589: Implementation of Alpine Linux/x64 Port ------------- Changes: https://git.openjdk.java.net/jdk/pull/49/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=05 Stats: 403 lines in 30 files changed: 348 ins; 17 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk/pull/49 From avoitylov at openjdk.java.net Thu Oct 8 11:03:48 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Thu, 8 Oct 2020 11:03:48 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com> Message-ID: On Thu, 8 Oct 2020 10:58:56 GMT, Aleksei Voitylov wrote: >> @voitylov For future reference please don't force-push commits on open PRs as it breaks the commit history. I can no >> longer just look at the two most recent commits and see what they added relative to what I had previously reviewed. >> Thanks. > > @dholmes-ora yes, sorry about that. I updated the branch to pull the recent changes to enable pre-submit tests and > ensure everything is well before integration and though the branch looked good it confused the pull request. So I had > to force push it back to the original state. @iignatev I resolved the conflict in whitebox.cpp and fixed a minor style nit on the way. Could you take a look? ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From avoitylov at openjdk.java.net Thu Oct 8 11:03:48 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Thu, 8 Oct 2020 11:03:48 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com> Message-ID: On Tue, 6 Oct 2020 02:00:06 GMT, David Holmes wrote: >> I added the contributors that could be found in the portola project commits. If anyone knows some other contributors I >> missed, I'll be happy to stand corrected. > > @voitylov For future reference please don't force-push commits on open PRs as it breaks the commit history. I can no > longer just look at the two most recent commits and see what they added relative to what I had previously reviewed. > Thanks. @dholmes-ora yes, sorry about that. I updated the branch to pull the recent changes to enable pre-submit tests and ensure everything is well before integration and though the branch looked good it confused the pull request. So I had to force push it back to the original state. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From sgehwolf at openjdk.java.net Thu Oct 8 12:51:54 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 8 Oct 2020 12:51:54 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v5] In-Reply-To: References: Message-ID: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also > to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific > objects. In order to not regress here, I've added more tests. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/5e2ca2dc..e72ac219 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=03-04 Stats: 514 lines in 5 files changed: 159 ins; 231 del; 124 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Thu Oct 8 12:51:54 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 8 Oct 2020 12:51:54 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 10:10:23 GMT, Severin Gehwolf wrote: >>> The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed. >> >> Thanks for the review and for testing it! > > @bobvandette Could you perhaps have a look at this? Many thanks in advance! @bobvandette How about this? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From bobv at openjdk.java.net Thu Oct 8 13:14:46 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Thu, 8 Oct 2020 13:14:46 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v5] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 12:51:54 GMT, Severin Gehwolf wrote: >> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd >> >> >> Note that `/proc/cgroups` looks like this: >> >> #subsys_name hierarchy num_cgroups enabled >> cpuset 0 1 1 >> cpu 0 1 1 >> cpuacct 0 1 1 >> blkio 0 1 1 >> memory 0 1 1 >> devices 0 1 1 >> freezer 0 1 1 >> net_cls 0 1 1 >> perf_event 0 1 1 >> net_prio 0 1 1 >> hugetlb 0 1 1 >> pids 0 1 1 >> >> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo >> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in >> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, >> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to >> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's >> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also >> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific >> objects. In order to not regress here, I've added more tests. >> **Testing** >> >> - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) >> - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) >> - [x] Added regression test which fails prior the patch and passes after >> - [x] Submit testing > > Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 185: > 183: } else { > 184: // fallback to old, pre JDK-8245543, behaviour > 185: return line.contains("cgroup"); Why are you doing this fallback rather than returning false?? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Thu Oct 8 13:38:59 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 8 Oct 2020 13:38:59 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: Message-ID: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also > to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific > objects. In order to not regress here, I've added more tests. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Return false in case of no pattern match ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/e72ac219..37f5b093 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=04-05 Stats: 7 lines in 1 file changed: 2 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Thu Oct 8 13:39:00 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 8 Oct 2020 13:39:00 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v5] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:12:02 GMT, Bob Vandette wrote: >> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. The pull request contains one new >> commit since the last revision: >> 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 185: > >> 183: } else { >> 184: // fallback to old, pre JDK-8245543, behaviour >> 185: return line.contains("cgroup"); > > Why are you doing this fallback rather than returning false?? The idea was to have have some basics working even though the pattern doesn't match for some reason. I guess we can remove that as it's rather unlikely to not match. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From bobv at openjdk.java.net Thu Oct 8 14:03:48 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Thu, 8 Oct 2020 14:03:48 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:38:59 GMT, Severin Gehwolf wrote: >> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd >> >> >> Note that `/proc/cgroups` looks like this: >> >> #subsys_name hierarchy num_cgroups enabled >> cpuset 0 1 1 >> cpu 0 1 1 >> cpuacct 0 1 1 >> blkio 0 1 1 >> memory 0 1 1 >> devices 0 1 1 >> freezer 0 1 1 >> net_cls 0 1 1 >> perf_event 0 1 1 >> net_prio 0 1 1 >> hugetlb 0 1 1 >> pids 0 1 1 >> >> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo >> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in >> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, >> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to >> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's >> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also >> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific >> objects. In order to not regress here, I've added more tests. >> **Testing** >> >> - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) >> - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) >> - [x] Added regression test which fails prior the patch and passes after >> - [x] Submit testing > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Return false in case of no pattern match Marked as reviewed by bobv (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From bobv at openjdk.java.net Thu Oct 8 14:03:50 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Thu, 8 Oct 2020 14:03:50 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v5] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:36:20 GMT, Severin Gehwolf wrote: >> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 185: >> >>> 183: } else { >>> 184: // fallback to old, pre JDK-8245543, behaviour >>> 185: return line.contains("cgroup"); >> >> Why are you doing this fallback rather than returning false?? > > The idea was to have have some basics working even though the pattern doesn't match for some reason. I guess we can > remove that as it's rather unlikely to not match. The change looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Thu Oct 8 14:49:46 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 8 Oct 2020 14:49:46 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 14:01:26 GMT, Bob Vandette wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Return false in case of no pattern match > > Marked as reviewed by bobv (Committer). Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From rrich at openjdk.java.net Thu Oct 8 16:55:31 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 8 Oct 2020 16:55:31 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v9] In-Reply-To: References: Message-ID: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com> > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'master' into JDK-8227745 - Merge branch 'master' into JDK-8227745 - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame. - More smaller changes proposed by Serguei. - jvmtiDeferredUpdates.hpp: remove forward declarations. - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition. - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation. - Merge branch 'master' into JDK-8227745 - Merge branch 'master' into JDK-8227745 - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again. With Asynchronous handshakes the type was changed from JavaThread* to Thread* but this is not necessary as check_top_frame() is not executed during a handshake / safepoint (robehn confirmed). - ... and 9 more: https://git.openjdk.java.net/jdk/compare/d036dca0...d463b4f3 ------------- Changes: https://git.openjdk.java.net/jdk/pull/119/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=08 Stats: 5814 lines in 52 files changed: 5595 ins; 116 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From iignatyev at openjdk.java.net Thu Oct 8 18:41:23 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 8 Oct 2020 18:41:23 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com> Message-ID: On Thu, 8 Oct 2020 11:00:41 GMT, Aleksei Voitylov wrote: > @iignatev I resolved the conflict in whitebox.cpp and fixed a minor style nit on the way. Could you take a look? LGTM ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From dholmes at openjdk.java.net Fri Oct 9 06:04:26 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 9 Oct 2020 06:04:26 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v6] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 10:52:53 GMT, Aleksei Voitylov wrote: >> continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html >> >>> The download side of using JNI in these tests is that it complicates the >>> setup a bit for those that run jtreg directly and/or just build the JDK >>> and not the test libraries. You could reduce this burden a bit by >>> limiting the load library/isMusl check to Linux only, meaning isMusl >>> would not be called on other platforms. >>> >>> The alternative you suggest above might indeed be better. I assume you >>> don't mean splitting the tests but rather just adding a second @test >>> description so that the vm.musl case runs the test with a system >>> property that allows the test know the expected load library path behavior. >> >> I have updated the PR to split the two tests in multiple @test s. >> >>> The updated comment in java_md.c in this looks good. A minor comment on >>> Platform.isBusybox is Files.isSymbolicLink returning true implies that >>> the link exists so no need to check for exists too. Also the >>> if-then-else style for the new class in ProcessBuilder/Basic.java is >>> inconsistent with the rest of the test so it stands out. >> >> Thank you, these changes are done in the updated PR. >> >>> Given the repo transition this weekend then I assume you'll create a PR >>> for the final review at least. Also I see JEP 386 hasn't been targeted >>> yet but I assume Boris, as owner, will propose-to-target and wait for it >>> to be targeted before it is integrated. >> >> Yes. How can this be best accomplished with the new git workflow? >> - we can continue the review process till the end and I will request the integration to happen only after the JEP is >> targeted. I guess this step is now done by typing "slash integrate" in a comment. >> - we can pause the review process now until the JEP is targeted. >> >> In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. > > Aleksei Voitylov has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains three commits: > - Merge branch 'master' into JDK-8247589 > - JDK-8247589: Implementation of Alpine Linux/x64 Port > - JDK-8247589: Implementation of Alpine Linux/x64 Port Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From eosterlund at openjdk.java.net Fri Oct 9 07:56:39 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 9 Oct 2020 07:56:39 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v13] In-Reply-To: References: Message-ID: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'master' into 8253180_conc_stack_scanning - Review: Andrew CR 1 - Review: David CR 1 - Review: Deal with new assert from mainline - Merge branch 'master' into 8253180_conc_stack_scanning - Review: StackWalker hook - Review: Kim CR 1 and exception handling fix - Review: Move barrier detach - Review: Remove assert that has outstayed its welcome - Merge branch 'master' into 8253180_conc_stack_scanning - ... and 9 more: https://git.openjdk.java.net/jdk/compare/a2f65190...66070372 ------------- Changes: https://git.openjdk.java.net/jdk/pull/296/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=12 Stats: 2740 lines in 131 files changed: 2167 ins; 311 del; 262 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Fri Oct 9 08:43:25 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 9 Oct 2020 08:43:25 GMT Subject: Integrated: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 11:43:41 GMT, Erik ?sterlund wrote: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. This pull request has now been integrated. Changeset: b9873e18 Author: Erik ?sterlund URL: https://git.openjdk.java.net/jdk/commit/b9873e18 Stats: 2740 lines in 131 files changed: 2167 ins; 311 del; 262 mod 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing Reviewed-by: stefank, pliden, rehn, neliasso, coleenp, smonteith ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From shade at openjdk.java.net Fri Oct 9 09:27:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Oct 2020 09:27:20 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: Message-ID: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com> On Thu, 8 Oct 2020 13:38:59 GMT, Severin Gehwolf wrote: >> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd >> >> >> Note that `/proc/cgroups` looks like this: >> >> #subsys_name hierarchy num_cgroups enabled >> cpuset 0 1 1 >> cpu 0 1 1 >> cpuacct 0 1 1 >> blkio 0 1 1 >> memory 0 1 1 >> devices 0 1 1 >> freezer 0 1 1 >> net_cls 0 1 1 >> perf_event 0 1 1 >> net_prio 0 1 1 >> hugetlb 0 1 1 >> pids 0 1 1 >> >> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo >> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in >> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, >> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to >> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's >> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also >> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific >> objects. In order to not regress here, I've added more tests. >> **Testing** >> >> - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) >> - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) >> - [x] Added regression test which fails prior the patch and passes after >> - [x] Submit testing > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Return false in case of no pattern match This looks fine to me. Consider a minor nit below. src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 183: > 181: } > 182: } > 183: return relevantControllerFound; If I am reading the code right, then `relevantControllerFound` can be replaced with just `return true` or `return false`? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Fri Oct 9 09:49:19 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 9 Oct 2020 09:49:19 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com> References: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com> Message-ID: On Fri, 9 Oct 2020 09:23:22 GMT, Aleksey Shipilev wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Return false in case of no pattern match > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 183: > >> 181: } >> 182: } >> 183: return relevantControllerFound; > > If I am reading the code right, then `relevantControllerFound` can be replaced with just `return true` or `return > false`? I don't think so. It starts out as `false` and is being set to true on lines 180 and 174. So we could change it to `return false` here iff lines 174 and 180 would `return true`. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From shade at openjdk.java.net Fri Oct 9 09:54:19 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Oct 2020 09:54:19 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com> Message-ID: On Fri, 9 Oct 2020 09:46:55 GMT, Severin Gehwolf wrote: >> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 183: >> >>> 181: } >>> 182: } >>> 183: return relevantControllerFound; >> >> If I am reading the code right, then `relevantControllerFound` can be replaced with just `return true` or `return >> false`? > > I don't think so. It starts out as `false` and is being set to true on lines 180 and 174. So we could change it to > `return false` here iff lines 174 and 180 would `return true`. Yes, that's what I meant: instead of dragging the boolean flag, do the early `return true`, or `return false` otherwise. Your choice if you want to make that change. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Fri Oct 9 10:24:34 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 9 Oct 2020 10:24:34 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v7] In-Reply-To: References: Message-ID: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also > to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific > objects. In order to not regress here, I've added more tests. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Drop local variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/37f5b093..c18be739 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=05-06 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Fri Oct 9 10:24:34 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 9 Oct 2020 10:24:34 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com> Message-ID: On Fri, 9 Oct 2020 09:51:29 GMT, Aleksey Shipilev wrote: >> I don't think so. It starts out as `false` and is being set to true on lines 180 and 174. So we could change it to >> `return false` here iff lines 174 and 180 would `return true`. > > Yes, that's what I meant: instead of dragging the boolean flag, do the early `return true`, or `return false` > otherwise. Your choice if you want to make that change. OK, done. Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sjohanss at openjdk.java.net Fri Oct 9 11:13:20 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 9 Oct 2020 11:13:20 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap In-Reply-To: References: Message-ID: <1xp0kyi05gXKng-W44aZ---XzUKoTi0KyQnagMml74c=.10a80aa0-ba28-4f96-9f2a-867aa68496d0@github.com> On Fri, 11 Sep 2020 07:25:37 GMT, Lin Zang wrote: >> - Parallel heap iteration support for PSS >> - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 > > Dear All, > May I ask your help to review this PR? Thanks! > -Lin Hi Lin, Sorry for not getting to this sooner. One of the reasons is that I haven't had time to explore a better solution, but the above notification triggered me to at least share my thoughts. I would like us to avoid having the logic that check how many workers are doing the work and instead have some mechanism that claim different chunks of work. You can compare it a bit to G1 where we have the `HeapRegionClaimer` that make sure only one thread handles a given region. This claimer needs to be a bit different and allow claiming of eden, to-space, from-space and then multiple chunks of old. But I believe such solution would both be more efficient (since all threads can help out on old in the end) and easier to follow (no special cases). So basically the `PSScavengeParallelObjectIterator` need to set up this claimer and pass it down to the workers and all workers than try to do all work, but only the one getting the claim will do the actual work. What do you think about this approach? Do you understand what I'm after? ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From github.com+670087+jrziviani at openjdk.java.net Fri Oct 9 13:00:12 2020 From: github.com+670087+jrziviani at openjdk.java.net (Ziviani) Date: Fri, 9 Oct 2020 13:00:12 GMT Subject: Integrated: 8253900: SA: wrong size computation when JVM was built without AOT In-Reply-To: References: Message-ID: <7y7E1QZytgQzEdRi3LU__E97QBcaOUvB-DNrJiEa_cQ=.79187b75-a950-4929-a0f9-59450ef678ca@github.com> On Fri, 25 Sep 2020 13:13:44 GMT, Ziviani wrote: > TestInstanceKlassSize was failing because, for PowerPC, the following code (instanceKlass.cpp) always compiles to > `return false;` bool InstanceKlass::has_stored_fingerprint() const { > #if INCLUDE_AOT > return should_store_fingerprint() || is_shared(); > #else > return false; > #endif > } > However, in `hasStoredFingerprint()@InstanceKlass.java` the condition `shouldStoreFingerprint() || isShared();` is > always evaluated and may return true (_AFAIK isShared() returns true_). Such condition adds 8 bytes in the > `getSize()@InstanceKlass.java` causing the failure in TestInstanceKlassSize: public long getSize() { // in number of > bytes > ... > if (hasStoredFingerprint()) { > size += 8; // uint64_t > } > return alignSize(size); > } > Considering these tests are failing for PowerPC only (_based on ProblemList.txt_), my solution checks if > `hasStoredFingerprint()` is running on a PowerPC platform. I decided to go this way because there is no existing flag > informing whether AOT is included or not and creating a new one just to handle the PowerPC case seems too much. This > patch is an attempt to fix https://bugs.openjdk.java.net/browse/JDK-8230664 This pull request has now been integrated. Changeset: b1448da1 Author: Jose Ricardo Ziviani Committer: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/b1448da1 Stats: 27 lines in 6 files changed: 24 ins; 2 del; 1 mod 8253900: SA: wrong size computation when JVM was built without AOT Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From lzang at openjdk.java.net Fri Oct 9 14:19:10 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 9 Oct 2020 14:19:10 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap In-Reply-To: <1xp0kyi05gXKng-W44aZ---XzUKoTi0KyQnagMml74c=.10a80aa0-ba28-4f96-9f2a-867aa68496d0@github.com> References: <1xp0kyi05gXKng-W44aZ---XzUKoTi0KyQnagMml74c=.10a80aa0-ba28-4f96-9f2a-867aa68496d0@github.com> Message-ID: <3Ht7FuvxDYvrvOF0u1hFihHmSnQsSTldXcNORnGOE84=.2770966d-051f-4202-a4d6-0bc071faa1a7@github.com> On Fri, 9 Oct 2020 11:10:14 GMT, Stefan Johansson wrote: >> Dear All, >> May I ask your help to review this PR? Thanks! >> -Lin > > Hi Lin, > > Sorry for not getting to this sooner. One of the reasons is that I haven't had time to explore a better solution, but > the above notification triggered me to at least share my thoughts. > I would like us to avoid having the logic that check how many workers are doing the work and instead have some > mechanism that claim different chunks of work. You can compare it a bit to G1 where we have the `HeapRegionClaimer` > that make sure only one thread handles a given region. This claimer needs to be a bit different and allow claiming of > eden, to-space, from-space and then multiple chunks of old. But I believe such solution would both be more efficient > (since all threads can help out on old in the end) and easier to follow (no special cases). So basically the > `PSScavengeParallelObjectIterator` need to set up this claimer and pass it down to the workers and all workers than try > to do all work, but only the one getting the claim will do the actual work. What do you think about this approach? Do > you understand what I'm after? Hi @kstefanj, Thanks a lot for your comments. I think there can be a reclaimer that treat eden space, from space, to space and "blocks" in old space as parallel iteration candidates, then every workers try to claim their ownership of the candidate that it is going to scan. So there is no need to check worker numbers and Id for processing different spaces. what do you think? BTW, Paul (hohensee at amazon.com) also helped review this patch and send the comment in mail list, I will paste his comments here and then try to polish a patch with all of your comments considered. ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From lzang at openjdk.java.net Fri Oct 9 14:26:13 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 9 Oct 2020 14:26:13 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap In-Reply-To: <3Ht7FuvxDYvrvOF0u1hFihHmSnQsSTldXcNORnGOE84=.2770966d-051f-4202-a4d6-0bc071faa1a7@github.com> References: <1xp0kyi05gXKng-W44aZ---XzUKoTi0KyQnagMml74c=.10a80aa0-ba28-4f96-9f2a-867aa68496d0@github.com> <3Ht7FuvxDYvrvOF0u1hFihHmSnQsSTldXcNORnGOE84=.2770966d-051f-4202-a4d6-0bc071faa1a7@github.com> Message-ID: On Fri, 9 Oct 2020 14:16:51 GMT, Lin Zang wrote: >> Hi Lin, >> >> Sorry for not getting to this sooner. One of the reasons is that I haven't had time to explore a better solution, but >> the above notification triggered me to at least share my thoughts. >> I would like us to avoid having the logic that check how many workers are doing the work and instead have some >> mechanism that claim different chunks of work. You can compare it a bit to G1 where we have the `HeapRegionClaimer` >> that make sure only one thread handles a given region. This claimer needs to be a bit different and allow claiming of >> eden, to-space, from-space and then multiple chunks of old. But I believe such solution would both be more efficient >> (since all threads can help out on old in the end) and easier to follow (no special cases). So basically the >> `PSScavengeParallelObjectIterator` need to set up this claimer and pass it down to the workers and all workers than try >> to do all work, but only the one getting the claim will do the actual work. What do you think about this approach? Do >> you understand what I'm after? > > Hi @kstefanj, Thanks a lot for your comments. > I think there can be a reclaimer that treat eden space, from space, to space and "blocks" in old space as parallel > iteration candidates, then every workers try to claim their ownership of the candidate that it is going to scan. So > there is no need to check worker numbers and Id for processing different spaces. what do you think? > BTW, Paul (hohensee at amazon.com) also helped review this patch and send the comment in mail list, I will paste his > comments here and then try to polish a patch with all of your comments considered. Here is the review comments from Paul, copied from hotspot-gc-dev digest: > Message: 3 > Date: Mon, 28 Sep 2020 22:39:38 +0000 > From: "Hohensee, Paul" > To: Lin Zang , > "hotspot-gc-dev at openjdk.java.net" , > "serviceability-dev at openjdk.java.net" > > Subject: RE: RFR: 8252103: Parallel heap inspection for > ParallelScavengeHeap > Message-ID: <25A4DC80-74A8-4C99-AEF4-7E989317B18A at amazon.com> > Content-Type: text/plain; charset="utf-8" > > I'm not a GC specialist, but your approach looks reasonable to me. > > parallelScavengeHeap.cpp: > > "less that 1 workers" -> "less that 1 worker" > > psOldGen.cpp: > > ">=2" -> ">= 2" > > "thread_num-2 worker" -> "(thread_num -2) workers" > > "cross blocks" -> "crosses blocks" > > "that the object start address locates in the related block" -> "that owns the block within which the object starts" > > blocks_iterate_parallel() relies on BLOCK_SIZE being an integral multiple of a start_array() block (i.e., > ObjectStartArray::block_size). I'd add an assert to that effect. > The comment on the definition of BLOCK_SIZE is "64 KB", but you're doing pointer arithmetic in terms of HeapWords, > which > means the actual byte value is either 256KB or 512KB for 32- and 64-bit respectively. You could use > const int BLOCK_SIZE = (64 * 1024 / HeapWordSize); > > "// There is objects" -> "There are objects" > > "reture" -> "return" > > ", here only focus objects" -> ". Here only focus on objects" > > It's a matter of taste, but imo the loop in blocks_iterate_parallel() would be more clear as > > for (HeapWord* p = start; p < end; p += oop(p)->size()) { > cl->do_object(oop(p)); > } > > psOldGen.hpp: > > blocks_iterate_parallel() is pure implementation and I don't see a reference outside psOldGen.cpp. So, it should be > private, > not public. > > psYoungGen.cpp: > > "<=1" -> "<= 1" > > Thanks, > Paul Thanks for Paul's help and effort for reviewing, I will make a refined patch based on your comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From sgehwolf at openjdk.java.net Fri Oct 9 16:29:18 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 9 Oct 2020 16:29:18 GMT Subject: Integrated: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 16:34:49 GMT, Severin Gehwolf wrote: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also > to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific > objects. In order to not regress here, I've added more tests. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing This pull request has now been integrated. Changeset: 2bbf8a2a Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/2bbf8a2a Stats: 97 lines in 4 files changed: 91 ins; 1 del; 5 mod 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) Reviewed-by: bobv, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Fri Oct 9 16:29:18 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 9 Oct 2020 16:29:18 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v8] In-Reply-To: References: Message-ID: <_DreJpVrpxOcrH7gxEJKUJDhl4j1QEfaTsSSwzb2AyY=.a3befe30-3cf2-44a6-b86e-ebf108988651@github.com> > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also > to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific > objects. In order to not regress here, I've added more tests. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) ------------- Changes: https://git.openjdk.java.net/jdk/pull/485/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=07 Stats: 97 lines in 4 files changed: 91 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From kvn at openjdk.java.net Sat Oct 10 00:04:15 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 10 Oct 2020 00:04:15 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v9] In-Reply-To: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com> References: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com> Message-ID: On Thu, 8 Oct 2020 16:55:31 GMT, Richard Reingruber wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 19 commits: > - Merge branch 'master' into JDK-8227745 > - Merge branch 'master' into JDK-8227745 > - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame. > - More smaller changes proposed by Serguei. > - jvmtiDeferredUpdates.hpp: remove forward declarations. > - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition. > - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation. > - Merge branch 'master' into JDK-8227745 > - Merge branch 'master' into JDK-8227745 > - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again. > > With Asynchronous handshakes the type was changed from JavaThread* to Thread* > but this is not necessary as check_top_frame() is not executed during a handshake > / safepoint (robehn confirmed). > - ... and 9 more: https://git.openjdk.java.net/jdk/compare/d036dca0...d463b4f3 Compiler changes seems fine. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/119 From kvn at openjdk.java.net Sat Oct 10 00:28:13 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 10 Oct 2020 00:28:13 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v9] In-Reply-To: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com> References: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com> Message-ID: On Thu, 8 Oct 2020 16:55:31 GMT, Richard Reingruber wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 19 commits: > - Merge branch 'master' into JDK-8227745 > - Merge branch 'master' into JDK-8227745 > - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame. > - More smaller changes proposed by Serguei. > - jvmtiDeferredUpdates.hpp: remove forward declarations. > - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition. > - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation. > - Merge branch 'master' into JDK-8227745 > - Merge branch 'master' into JDK-8227745 > - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again. > > With Asynchronous handshakes the type was changed from JavaThread* to Thread* > but this is not necessary as check_top_frame() is not executed during a handshake > / safepoint (robehn confirmed). > - ... and 9 more: https://git.openjdk.java.net/jdk/compare/d036dca0...d463b4f3 I tried to run testing with latest changes and latest JDK and build failed: src/hotspot/share/runtime/escapeBarrier.cpp:310:35: error: no matching function for call to 'StackFrameStream::StackFrameStream(JavaThread*&)' 310 | StackFrameStream fst(deoptee); ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Sat Oct 10 08:34:23 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Sat, 10 Oct 2020 08:34:23 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v10] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - The constructor of StackFrameStream takes more parameters after JDK-8253180 - Merge branch 'master' into JDK-8227745 - Merge branch 'master' into JDK-8227745 - Merge branch 'master' into JDK-8227745 - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame. - More smaller changes proposed by Serguei. - jvmtiDeferredUpdates.hpp: remove forward declarations. - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition. - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation. - Merge branch 'master' into JDK-8227745 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/aaa0a2a0...06b139a9 ------------- Changes: https://git.openjdk.java.net/jdk/pull/119/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=09 Stats: 5814 lines in 52 files changed: 5595 ins; 116 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Sat Oct 10 08:37:12 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Sat, 10 Oct 2020 08:37:12 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v9] In-Reply-To: References: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com> Message-ID: On Sat, 10 Oct 2020 00:01:49 GMT, Vladimir Kozlov wrote: > > > Compiler changes seems fine. Thank you for looking again at this. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Sat Oct 10 09:05:11 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Sat, 10 Oct 2020 09:05:11 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v9] In-Reply-To: References: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com> Message-ID: On Sat, 10 Oct 2020 00:25:52 GMT, Vladimir Kozlov wrote: > > > I tried to run testing with latest changes and latest JDK and build failed: > src/hotspot/share/runtime/escapeBarrier.cpp:310:35: error: no matching function for call to > 'StackFrameStream::StackFrameStream(JavaThread*&)' 310 | StackFrameStream fst(deoptee); I noticed this too. I wanted to test with ZGC before pushing the small fix. Unfortunately I get # Internal Error (/priv/d038402/git/reinrich/jdk_ea_new/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), pid=90890, tid=90912 # assert(processing_started()) failed: Processing should already have started [...] Current thread (0x00007f749c25b1c0): JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_vm, id=90912, stack(0x00007f7474c9f000,0x00007f7474da0000)] _threads_hazard_ptr=0x00007f749c2b00c0, _nested_threads_hazard_ptr_cnt=0 Stack: [0x00007f7474c9f000,0x00007f7474da0000], sp=0x00007f7474d9c240, free space=1012k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x15b3255] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xa5 V [libjvm.so+0xa1024f] frame::sender(RegisterMap*) const+0x13f V [libjvm.so+0xa048f8] frame::real_sender(RegisterMap*) const+0x18 V [libjvm.so+0x176261b] vframe::sender() const+0xeb V [libjvm.so+0x16cd56b] JavaThread::last_java_vframe(RegisterMap*)+0x5b V [libjvm.so+0xfa7a56] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x46 V [libjvm.so+0xfab8e5] JvmtiEnvBase::check_top_frame(JavaThread*, JavaThread*, jvalue, TosState, Handle*)+0x1f5 V [libjvm.so+0xfac13e] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x15e V [libjvm.so+0xf36fa8] jvmti_ForceEarlyReturnLong+0x258 C [libjdwp.so+0xa8b3] forceEarlyReturn+0x293 C [libjdwp.so+0x12945] debugLoop_run+0x1f5 C [libjdwp.so+0x25bb3] attachThread+0x33 V [libjvm.so+0xfcf524] JvmtiAgentThread::call_start_function()+0x1d4 V [libjvm.so+0x16cc8f7] JavaThread::thread_main_inner()+0x247 V [libjvm.so+0x16d1ce8] Thread::call_run()+0xf8 V [libjvm.so+0x12dd75e] thread_native_entry(Thread*)+0x10e In the test case `EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure` of the new test `jdk/com/sun/jdi/EATests.java` So far I do not have an indication that the failure is caused by this change but when I run the test with -XX:-DoEscapeAnalysis then the test succeeds. I need to look more into it. Wish I was a ZGC expert :) Anyway I pushed the build fix. Tests succeed with default GC. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From iklam at openjdk.java.net Sun Oct 11 04:37:15 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Sun, 11 Oct 2020 04:37:15 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows Message-ID: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert to fail. **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to access each individual cloned vtable. **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just do the bare minimum to fix the bug, it will be pretty hard to review. I would suggest that the reviewers look at just the new version of the code and see if it's working as described (instead of looking at the diff to understand what the bug was and how it has been fixed). This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. I plan to change that into templates in a future RFE. ------------- Commit messages: - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows Changes: https://git.openjdk.java.net/jdk/pull/591/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254125 Stats: 136 lines in 5 files changed: 18 ins; 59 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/591/head:pull/591 PR: https://git.openjdk.java.net/jdk/pull/591 From rrich at openjdk.java.net Sun Oct 11 07:23:15 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Sun, 11 Oct 2020 07:23:15 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v9] In-Reply-To: References: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com> Message-ID: On Sat, 10 Oct 2020 09:01:22 GMT, Richard Reingruber wrote: >> I tried to run testing with latest changes and latest JDK and build failed: >> src/hotspot/share/runtime/escapeBarrier.cpp:310:35: error: no matching function for call to >> 'StackFrameStream::StackFrameStream(JavaThread*&)' >> 310 | StackFrameStream fst(deoptee); > >> >> >> I tried to run testing with latest changes and latest JDK and build failed: >> src/hotspot/share/runtime/escapeBarrier.cpp:310:35: error: no matching function for call to >> 'StackFrameStream::StackFrameStream(JavaThread*&)' 310 | StackFrameStream fst(deoptee); > > I noticed this too. I wanted to test with ZGC before pushing the small > fix. Unfortunately I get > > # Internal Error (/priv/d038402/git/reinrich/jdk_ea_new/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), > pid=90890, tid=90912 # assert(processing_started()) failed: Processing should already have started > > [...] > > Current thread (0x00007f749c25b1c0): JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_vm, id=90912, > stack(0x00007f7474c9f000,0x00007f7474da0000)] _threads_hazard_ptr=0x00007f749c2b00c0, _nested_threads_hazard_ptr_cnt=0 > Stack: [0x00007f7474c9f000,0x00007f7474da0000], sp=0x00007f7474d9c240, free space=1012k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x15b3255] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xa5 > V [libjvm.so+0xa1024f] frame::sender(RegisterMap*) const+0x13f > V [libjvm.so+0xa048f8] frame::real_sender(RegisterMap*) const+0x18 > V [libjvm.so+0x176261b] vframe::sender() const+0xeb > V [libjvm.so+0x16cd56b] JavaThread::last_java_vframe(RegisterMap*)+0x5b > V [libjvm.so+0xfa7a56] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x46 > V [libjvm.so+0xfab8e5] JvmtiEnvBase::check_top_frame(JavaThread*, JavaThread*, jvalue, TosState, Handle*)+0x1f5 > V [libjvm.so+0xfac13e] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x15e > V [libjvm.so+0xf36fa8] jvmti_ForceEarlyReturnLong+0x258 > C [libjdwp.so+0xa8b3] forceEarlyReturn+0x293 > C [libjdwp.so+0x12945] debugLoop_run+0x1f5 > C [libjdwp.so+0x25bb3] attachThread+0x33 > V [libjvm.so+0xfcf524] JvmtiAgentThread::call_start_function()+0x1d4 > V [libjvm.so+0x16cc8f7] JavaThread::thread_main_inner()+0x247 > V [libjvm.so+0x16d1ce8] Thread::call_run()+0xf8 > V [libjvm.so+0x12dd75e] thread_native_entry(Thread*)+0x10e > > In the test case > `EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure` of the > new test `jdk/com/sun/jdi/EATests.java` > > So far I do not have an indication that the failure is caused by this change but > when I run the test with -XX:-DoEscapeAnalysis then the test succeeds. > > I need to look more into it. Wish I was a ZGC expert :) > > Anyway I pushed the build fix. Tests succeed with default GC. The crash described above happens after JDK-8253180 (https://github.com/openjdk/jdk/commit/b9873e18330b7e43ca47bc1c0655e7ab20828f7a) when executing `EATests.java` with ZGC: make run-test TEST=test/jdk/com/sun/jdi/EATests.java JTREG=VM_OPTIONS=-XX:+UseZGC My understanding of JDK-8253180 (and ZGC) is rather vague. To me it looks as if stackwalks outside of a safepoint/handshake on suspended threads are currently not supported. It would be my understanding that `StackWatermarkSet::start_processing()` needs to be called before walking the stack of a thread. Currently this is only done in preparation of a safepoint or handshake. `JvmtiEnvBase::check_top_frame()` walks the stack of a suspended thread without safepoint/handshake. This triggers the crash in my opinion. When `StackWatermarkSet::start_processing()` is called before the test succeeds. I will ask Erik ?sterlund about this. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From iklam at openjdk.java.net Sun Oct 11 22:28:13 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Sun, 11 Oct 2020 22:28:13 GMT Subject: RFR: 8254364: Remove leading _ from struct/union declarations in jvmti.h Message-ID: This PR changes declarations in jvmti.h like the following from struct _jvmtiTimerInfo; typedef struct _jvmtiTimerInfo jvmtiTimerInfo; to struct jvmtiTimerInfo; typedef struct jvmtiTimerInfo jvmtiTimerInfo; This way, it becomes possible to make forward declaration in C++ code like this, without assuming the knowledge of the `struct _jvmtiTimerInfo` type: struct jvmtiTimerInfo; Please see bug report [JDK-8254364](https://bugs.openjdk.java.net/browse/JDK-8254364) for the before/after versions of jvmti.h, which is generated from XML. ------------- Commit messages: - 8254364: Remove leading _ from struct/union declarations in jvmti.h Changes: https://git.openjdk.java.net/jdk/pull/596/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=596&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254364 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/596.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/596/head:pull/596 PR: https://git.openjdk.java.net/jdk/pull/596 From dholmes at openjdk.java.net Mon Oct 12 00:52:08 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Oct 2020 00:52:08 GMT Subject: RFR: 8254364: Remove leading _ from struct/union declarations in jvmti.h In-Reply-To: References: Message-ID: On Sun, 11 Oct 2020 22:21:28 GMT, Ioi Lam wrote: > This PR changes declarations in jvmti.h like the following from > > struct _jvmtiTimerInfo; > typedef struct _jvmtiTimerInfo jvmtiTimerInfo; > > to > > struct jvmtiTimerInfo; > typedef struct jvmtiTimerInfo jvmtiTimerInfo; > > This way, it becomes possible to make forward declaration in C++ code like this, without assuming the knowledge of the > `struct _jvmtiTimerInfo` type: > struct jvmtiTimerInfo; > > Please see bug report [JDK-8254364](https://bugs.openjdk.java.net/browse/JDK-8254364) for the before/after versions of > jvmti.h, which is generated from XML. > Tested with build tiers 1-5 in Mach5. Hi Ioi, A little research indicates the problem of using the same name in the typedef and the structs pre-dates even ANSI C, so this change should be fine. Please wait for approval from serviceability team member before pushing though. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/596 From sspitsyn at openjdk.java.net Mon Oct 12 05:41:11 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 12 Oct 2020 05:41:11 GMT Subject: RFR: 8254364: Remove leading _ from struct/union declarations in jvmti.h In-Reply-To: References: Message-ID: On Sun, 11 Oct 2020 22:21:28 GMT, Ioi Lam wrote: > This PR changes declarations in jvmti.h like the following from > > struct _jvmtiTimerInfo; > typedef struct _jvmtiTimerInfo jvmtiTimerInfo; > > to > > struct jvmtiTimerInfo; > typedef struct jvmtiTimerInfo jvmtiTimerInfo; > > This way, it becomes possible to make forward declaration in C++ code like this, without assuming the knowledge of the > `struct _jvmtiTimerInfo` type: > struct jvmtiTimerInfo; > > Please see bug report [JDK-8254364](https://bugs.openjdk.java.net/browse/JDK-8254364) for the before/after versions of > jvmti.h, which is generated from XML. > Tested with build tiers 1-5 in Mach5. Hi Ioi, This change looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/596 From vkempik at openjdk.java.net Mon Oct 12 12:07:23 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 12 Oct 2020 12:07:23 GMT Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification [v2] In-Reply-To: References: Message-ID: > Please review this change for hotspot and one test. > There is few JVMTI callback/event functions in jdk which signature doesn't match specification. > for example: > static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, jboolean* enabled, ...) > but according to jvmti specs it should be: > static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, ...) > same with ClassUnload(jvmtiEnv* jvmti_env, JNIEnv* jni_env, const char* name, ...) in tests > for many years that didn't matter but with coming JEP-391 it becomes important to make it match the spec > https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code > This commit makes the above mentioned functions to have signature matching jvmti specification Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision: Add impl of CSR JDK-8254014 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/466/files - new: https://git.openjdk.java.net/jdk/pull/466/files/1ef832d2..cd7c4d53 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=466&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=466&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/466/head:pull/466 PR: https://git.openjdk.java.net/jdk/pull/466 From vkempik at openjdk.java.net Mon Oct 12 12:28:11 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 12 Oct 2020 12:28:11 GMT Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification [v2] In-Reply-To: References: <5UPvhVjwK3TOKrd2rSzeCz-xT0tXsCUkMT9R8tgFR8I=.f1723d22-6883-4ad3-af55-a7437ef905de@github.com> Message-ID: On Mon, 5 Oct 2020 12:44:34 GMT, Vladimir Kempik wrote: >>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on >>> [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ >>> Hi Vladimir, >>> >>> On 2/10/2020 5:37 pm, Vladimir Kempik wrote: >>> >>> > On Fri, 2 Oct 2020 07:27:17 GMT, David Holmes wrote: >>> > > Okay but look at the example that documentation gives: >>> > > > For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates that there is a jint parameter, the event >>> > > > handler should be declared: ``` >>> > > > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) >>> > > > ``` >>> > > >>> > > >>> > > The myInt is explicit, just as our "jboolean* enabled" is explicit. I think they key point is that the signature must >>> > > end with "..." which it does. >>> > > I don't see anything here that needs to be fixed. >>> > >>> > >>> > Hello David. On majority of platforms this would be fine. >>> > But on some platforms, variadic arguments and non variadic arguments are passed differently ( for example on >>> > macos-aarch64, variadic args are passed always on stack, non variadic on registers (and on stack for 9th+ arg) , that >>> > causes issues. >>> >>> Okay - I see the potential for a problme here but ... >>> >>> > If you still see no issues here we can delay and make this changeset part of JEP-391. >>> > But since this changeset isn't much macos-aarch64 specific, I thought it would be good to integrate it separately from >>> > jep-391. >>> >>> ... this change actually goes against the example in the spec, so if you >>> make this change it indicates the spec needs to be updated too. >>> >>> Cheers, >>> David >>> ----- >> >> Hello David >> >> I really believe the problem is in document here ( in examples) >> first, the doc clearly specify the type >> >> typedef jvmtiError (JNICALL *jvmtiExtensionFunction) >> (jvmtiEnv* jvmti_env, >> ...); >> >> then in examples it declares the function not matching this spec. >> >> Is it a good idea to update the docs in a separate bug ? >> >> Thanks, Vladimir > > Hello David > I have created CSR draft > https://bugs.openjdk.java.net/browse/JDK-8254014 > > Regards, Vladimir Hello I have updated the PR with changes from spec of CSR Regards, Vladimir ------------- PR: https://git.openjdk.java.net/jdk/pull/466 From dholmes at openjdk.java.net Mon Oct 12 13:03:20 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Oct 2020 13:03:20 GMT Subject: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification [v2] In-Reply-To: References: Message-ID: <2BRqQiAy2eXizRcLeuj1-R_F-Rxv-GcGKMkwFSNMaMU=.9837528f-f42e-48c5-a5e1-dfa3ff4289ef@github.com> On Mon, 12 Oct 2020 12:07:23 GMT, Vladimir Kempik wrote: >> Please review this change for hotspot and one test. >> There is few JVMTI callback/event functions in jdk which signature doesn't match specification. >> for example: >> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, jboolean* enabled, ...) >> but according to jvmti specs it should be: >> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, ...) >> same with ClassUnload(jvmtiEnv* jvmti_env, JNIEnv* jni_env, const char* name, ...) in tests >> for many years that didn't matter but with coming JEP-391 it becomes important to make it match the spec >> https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code >> This commit makes the above mentioned functions to have signature matching jvmti specification > > Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision: > > Add impl of CSR JDK-8254014 Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/466 From vkempik at openjdk.java.net Mon Oct 12 13:20:14 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 12 Oct 2020 13:20:14 GMT Subject: Integrated: 8253899: Make IsClassUnloadingEnabled signature match specification In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 15:02:01 GMT, Vladimir Kempik wrote: > Please review this change for hotspot and one test. > There is few JVMTI callback/event functions in jdk which signature doesn't match specification. > for example: > static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, jboolean* enabled, ...) > but according to jvmti specs it should be: > static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, ...) > same with ClassUnload(jvmtiEnv* jvmti_env, JNIEnv* jni_env, const char* name, ...) in tests > for many years that didn't matter but with coming JEP-391 it becomes important to make it match the spec > https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code > This commit makes the above mentioned functions to have signature matching jvmti specification This pull request has now been integrated. Changeset: c7f00640 Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk/commit/c7f00640 Stats: 20 lines in 3 files changed: 17 ins; 0 del; 3 mod 8253899: Make IsClassUnloadingEnabled signature match specification Reviewed-by: sspitsyn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/466 From sgehwolf at openjdk.java.net Mon Oct 12 13:29:20 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 12 Oct 2020 13:29:20 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code for Java Message-ID: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). This patch alleviates that. Thoughts? ------------- Commit messages: - 8253939: [TESTBUG] Increase coverage of the cgroups detection code for Java Changes: https://git.openjdk.java.net/jdk/pull/609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253939 Stats: 40 lines in 1 file changed: 27 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/609/head:pull/609 PR: https://git.openjdk.java.net/jdk/pull/609 From shade at openjdk.java.net Mon Oct 12 17:53:15 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 12 Oct 2020 17:53:15 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows In-Reply-To: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Sun, 11 Oct 2020 04:04:56 GMT, Ioi Lam wrote: > **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in > memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each > of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert > to fail. > > **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to > access each individual cloned vtable. > > **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just > do the bare minimum to fix the bug, it will be pretty hard to review. > > I would suggest that the reviewers look at just the new version of the code and see if it's working as described > (instead of looking at the diff to understand what the bug was and how it has been fixed). > This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. > I plan to change that into templates in a future RFE. This looks reasonable to me, but after testing it on x86_32, I wonder if https://bugs.openjdk.java.net/browse/JDK-8254606 is the problem with this patch, or a different issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From amenkov at openjdk.java.net Mon Oct 12 21:09:19 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 12 Oct 2020 21:09:19 GMT Subject: RFR: 8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly Message-ID: <-d8IM-dOKNuxCl-f4xc-FQFWxeIxh0bkqnJx2LreaGU=.d03bda3d-b015-43de-a597-e9964c74cf33@github.com> Please review a trivial fix for JdwpAttachTest ------------- Commit messages: - 8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly Changes: https://git.openjdk.java.net/jdk/pull/619/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=619&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254345 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/619.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/619/head:pull/619 PR: https://git.openjdk.java.net/jdk/pull/619 From vromero at openjdk.java.net Mon Oct 12 21:35:36 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 12 Oct 2020 21:35:36 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v11] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implementing Record Classes as a standard feature in Java Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into JDK-8246774 - removing unused jcod file - remove unnecessary jtreg tags from tests, remove othervm etc when applicable - adding missing changes to some tests - modifiying @since from 14 to 16 - Remove preview args from ObjectMethodsTest - Remove preview args from record serialization tests - removing the javax.lang.model related code to be moved to a separate bug - 8246774: Record Classes (final) implementation Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Jonathan Gibbons Co-authored-by: Brian Goetz Co-authored-by: Maurizio Cimadamore Co-authored-by: Joe Darcy Co-authored-by: Chris Hegarty Co-authored-by: Jan Lahoda ------------- Changes: https://git.openjdk.java.net/jdk/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=10 Stats: 856 lines in 109 files changed: 64 ins; 552 del; 240 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From cjplummer at openjdk.java.net Mon Oct 12 21:42:18 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 12 Oct 2020 21:42:18 GMT Subject: RFR: 8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly In-Reply-To: <-d8IM-dOKNuxCl-f4xc-FQFWxeIxh0bkqnJx2LreaGU=.d03bda3d-b015-43de-a597-e9964c74cf33@github.com> References: <-d8IM-dOKNuxCl-f4xc-FQFWxeIxh0bkqnJx2LreaGU=.d03bda3d-b015-43de-a597-e9964c74cf33@github.com> Message-ID: On Mon, 12 Oct 2020 21:03:55 GMT, Alex Menkov wrote: > Please review a trivial fix for JdwpAttachTest I think you got this backward. `expectedResult` indicates whether or not a successful attach was expected. Since we are not in the exception handling part of the code here, that means it did succeed, but the else part is handling the case where we did not expect it to succeed. Therefore the error message is correct, basically saying the attached succeeded but shouldn't have. However, if you look in the exception handling block, that's were the code message is wrong. That's that code that is executed when the attach failed. If it was not expected to fail, the code should complain that it was NOT able to attach, but instead it complains that it was able to attach. You might want to change both messages to be a bit more clear. Something like "Attached succeeded but was expected to fail" and "Attach failed but was expected to succeed". ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/619 From amenkov at openjdk.java.net Mon Oct 12 23:11:33 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 12 Oct 2020 23:11:33 GMT Subject: RFR: 8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly [v2] In-Reply-To: <-d8IM-dOKNuxCl-f4xc-FQFWxeIxh0bkqnJx2LreaGU=.d03bda3d-b015-43de-a597-e9964c74cf33@github.com> References: <-d8IM-dOKNuxCl-f4xc-FQFWxeIxh0bkqnJx2LreaGU=.d03bda3d-b015-43de-a597-e9964c74cf33@github.com> Message-ID: > Please review a trivial fix for JdwpAttachTest Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: updated log/error messages accordingly Chris' suggestion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/619/files - new: https://git.openjdk.java.net/jdk/pull/619/files/d679032d..dbfb932c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=619&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=619&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/619.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/619/head:pull/619 PR: https://git.openjdk.java.net/jdk/pull/619 From amenkov at openjdk.java.net Mon Oct 12 23:11:34 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 12 Oct 2020 23:11:34 GMT Subject: RFR: 8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly [v2] In-Reply-To: References: <-d8IM-dOKNuxCl-f4xc-FQFWxeIxh0bkqnJx2LreaGU=.d03bda3d-b015-43de-a597-e9964c74cf33@github.com> Message-ID: On Mon, 12 Oct 2020 21:39:05 GMT, Chris Plummer wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> updated log/error messages accordingly Chris' suggestion > > I think you got this backward. `expectedResult` indicates whether or not a successful attach was expected. Since we are > not in the exception handling part of the code here, that means it did succeed, but the else part is handling the case > where we did not expect it to succeed. Therefore the error message is correct, basically saying the attached succeeded > but shouldn't have. However, if you look in the exception handling block, that's were the code message is wrong. That's > that code that is executed when the attach failed. If it was not expected to fail, the code should complain that it was > NOT able to attach, but instead it complains that it was able to attach. You might want to change both messages to be > a bit more clear. Something like "Attached succeeded but was expected to fail" and "Attach failed but was expected to > succeed". @plummercj Yes, you are right. Thank you for the catch. I updated all 4 messages for consistency ------------- PR: https://git.openjdk.java.net/jdk/pull/619 From sspitsyn at openjdk.java.net Tue Oct 13 02:09:16 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 13 Oct 2020 02:09:16 GMT Subject: RFR: 8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly [v2] In-Reply-To: References: <-d8IM-dOKNuxCl-f4xc-FQFWxeIxh0bkqnJx2LreaGU=.d03bda3d-b015-43de-a597-e9964c74cf33@github.com> Message-ID: On Mon, 12 Oct 2020 23:11:33 GMT, Alex Menkov wrote: >> Please review a trivial fix for JdwpAttachTest > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated log/error messages accordingly Chris' suggestion Hi Alex, It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/619 From iklam at openjdk.java.net Tue Oct 13 05:26:12 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Oct 2020 05:26:12 GMT Subject: Integrated: 8254364: Remove leading _ from struct/union declarations in jvmti.h In-Reply-To: References: Message-ID: On Sun, 11 Oct 2020 22:21:28 GMT, Ioi Lam wrote: > This PR changes declarations in jvmti.h like the following from > > struct _jvmtiTimerInfo; > typedef struct _jvmtiTimerInfo jvmtiTimerInfo; > > to > > struct jvmtiTimerInfo; > typedef struct jvmtiTimerInfo jvmtiTimerInfo; > > This way, it becomes possible to make forward declaration in C++ code like this, without assuming the knowledge of the > `struct _jvmtiTimerInfo` type: > struct jvmtiTimerInfo; > > Please see bug report [JDK-8254364](https://bugs.openjdk.java.net/browse/JDK-8254364) for the before/after versions of > jvmti.h, which is generated from XML. > Tested with build tiers 1-5 in Mach5. This pull request has now been integrated. Changeset: c9ca1bb0 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/c9ca1bb0 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod 8254364: Remove leading _ from struct/union declarations in jvmti.h Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/596 From iklam at openjdk.java.net Tue Oct 13 05:38:26 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Oct 2020 05:38:26 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v2] In-Reply-To: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: > **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in > memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each > of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert > to fail. > > **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to > access each individual cloned vtable. > > **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just > do the bare minimum to fix the bug, it will be pretty hard to review. > > I would suggest that the reviewers look at just the new version of the code and see if it's working as described > (instead of looking at the diff to understand what the bug was and how it has been fixed). > This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. > I plan to change that into templates in a future RFE. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/591/files - new: https://git.openjdk.java.net/jdk/pull/591/files/addaae99..50dfb2e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=00-01 Stats: 6758 lines in 165 files changed: 3923 ins; 1067 del; 1768 mod Patch: https://git.openjdk.java.net/jdk/pull/591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/591/head:pull/591 PR: https://git.openjdk.java.net/jdk/pull/591 From iklam at openjdk.java.net Tue Oct 13 06:06:12 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Oct 2020 06:06:12 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v2] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Mon, 12 Oct 2020 17:50:31 GMT, Aleksey Shipilev wrote: > This looks reasonable to me, but after testing it on x86_32, I wonder if > https://bugs.openjdk.java.net/browse/JDK-8254606 is the problem with this patch, or a different issue. [JDK-8254606](https://bugs.openjdk.java.net/browse/JDK-8254606) is also caused by [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), which has missed some cases where `align_up(xxx, SharedSpaceObjectAlignment)` is necessary. Since the cppVtables assertion fix cannot be easily validated by itself, I've decided to also include the `align_up` fixes in this PR. I have tested the fix on linux-x86 (32-bit) but the latest repo seems a bit flaky. Even if I disable CDS, sometime I get failures in (non-CDS) test cases like `There cannot be a NullPointerException at bci 14 of method byte java.lang.String.coder()`. I was able to run all 200+ CDS tests cases, and I would get about 5 failures due with the above error message. If I ran the failed tests again, they passed. So I **think** I have fixed the 32-bit issues with CDS, but there are probably other problems with the 32-bit build. Note that Oracle no longer supports the 32-bit x86 VMs. So my fix is intended to ensure that the CDS code is using SharedSpaceObjectAlignment properly, and I can only test thoroughly on our supported platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From shade at openjdk.java.net Tue Oct 13 06:11:09 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 13 Oct 2020 06:11:09 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v2] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Tue, 13 Oct 2020 06:03:20 GMT, Ioi Lam wrote: > I have tested the fix on linux-x86 (32-bit) but the latest repo seems a bit flaky. Even if I disable CDS, sometime I > get failures in (non-CDS) test cases like `There cannot be a NullPointerException at bci 14 of method byte > java.lang.String.coder()`. That's https://bugs.openjdk.java.net/browse/JDK-8254611 -- I integrated the fix, please merge from master. That said, there are a few failing tests in `tier1` anyway, you can ignore them: - gc/metaspace/TestCapacityUntilGCWrapAround.java - java/foreign/TestMismatch.java - java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java - tools/javac/lambda/T8031967.java ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From iklam at openjdk.java.net Tue Oct 13 06:46:27 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Oct 2020 06:46:27 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v3] In-Reply-To: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: > **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in > memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each > of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert > to fail. > > **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to > access each individual cloned vtable. > > **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just > do the bare minimum to fix the bug, it will be pretty hard to review. > > I would suggest that the reviewers look at just the new version of the code and see if it's working as described > (instead of looking at the diff to understand what the bug was and how it has been fixed). > This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. > I plan to change that into templates in a future RFE. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/591/files - new: https://git.openjdk.java.net/jdk/pull/591/files/50dfb2e2..5002b820 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=01-02 Stats: 27 lines in 8 files changed: 12 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/591/head:pull/591 PR: https://git.openjdk.java.net/jdk/pull/591 From iklam at openjdk.java.net Tue Oct 13 06:46:27 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Oct 2020 06:46:27 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v3] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Tue, 13 Oct 2020 06:08:11 GMT, Aleksey Shipilev wrote: > > I have tested the fix on linux-x86 (32-bit) but the latest repo seems a bit flaky. Even if I disable CDS, sometime I > > get failures in (non-CDS) test cases like `There cannot be a NullPointerException at bci 14 of method byte > > java.lang.String.coder()`. > > That's https://bugs.openjdk.java.net/browse/JDK-8254611 -- I integrated the fix, please merge from master. Thanks for the info. I merged and all CDS tests passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From shade at openjdk.java.net Tue Oct 13 06:53:13 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 13 Oct 2020 06:53:13 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v3] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Tue, 13 Oct 2020 06:46:27 GMT, Ioi Lam wrote: >> **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in >> memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each >> of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert >> to fail. >> >> **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to >> access each individual cloned vtable. >> >> **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just >> do the bare minimum to fix the bug, it will be pretty hard to review. >> >> I would suggest that the reviewers look at just the new version of the code and see if it's working as described >> (instead of looking at the diff to understand what the bug was and how it has been fixed). >> This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. >> I plan to change that into templates in a future RFE. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes > the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last > revision: > - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 > - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) > - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 > - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows I tested the new patch, and it passes `tier1` on `Linux x86_32` (well, with some known failures). ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/591 From cjplummer at openjdk.java.net Tue Oct 13 08:24:15 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 13 Oct 2020 08:24:15 GMT Subject: RFR: 8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly [v2] In-Reply-To: References: <-d8IM-dOKNuxCl-f4xc-FQFWxeIxh0bkqnJx2LreaGU=.d03bda3d-b015-43de-a597-e9964c74cf33@github.com> Message-ID: On Mon, 12 Oct 2020 23:11:33 GMT, Alex Menkov wrote: >> Please review a trivial fix for JdwpAttachTest > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated log/error messages accordingly Chris' suggestion Looks good! ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/619 From stefank at openjdk.java.net Tue Oct 13 09:33:24 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 13 Oct 2020 09:33:24 GMT Subject: RFR: 8254668: JVMTI process frames on thread without started processing In-Reply-To: References: Message-ID: <6LGnxhwhNPi4SdhuSvt5RF-jQzQ7QNPR7ndVc6Tt6HE=.7d468b7c-df34-4c44-823a-0e95f7abae32@github.com> On Tue, 13 Oct 2020 09:25:55 GMT, Stefan Karlsson wrote: > I hit the following assert in some tests runs that I've been doing: > # Internal Error (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), pid=828170, > tid=828734 # assert(processing_started()) failed: Processing should already have started > > The stack traces for this has been: > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 > V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a > V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 > V [libjvm.so+0x1804c4a] vframe::sender() const+0xea > V [libjvm.so+0x175f47b] JavaThread::last_java_vframe(RegisterMap*)+0x5b > V [libjvm.so+0x10e10fc] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x4c > V [libjvm.so+0x10e6972] JvmtiEnvBase::check_top_frame(Thread*, JavaThread*, jvalue, TosState, Handle*)+0xe2 > V [libjvm.so+0x10e759c] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x11c > V [libjvm.so+0x105b8f5] jvmti_ForceEarlyReturnObject+0x215 > V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 > V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a > V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 > V [libjvm.so+0x1804c4a] vframe::sender() const+0xea > V [libjvm.so+0x1804d00] vframe::java_sender() const+0x10 > V [libjvm.so+0x10e1115] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x65 > V [libjvm.so+0x10d475f] JvmtiEnv::NotifyFramePop(JavaThread*, int)+0x9f > V [libjvm.so+0x106b6aa] jvmti_NotifyFramePop+0x23a > The code inspects the top frame of a suspended java thread. However, there's nothing in the code that starts the > watermark processing of the thread, so the code asserts when sender calls on_iteration. > We only have to call start_processing/on_iteration when oops are being read. The failing code does *not* inspect any > oops, so I turn of the on_iteration call by settings process_frame to false. > To notify the readers of the code that vframeFor doesn't process the oops, I've renamed the function to > vframeForNoProcess to give a visual cue. > I found this bug when running this command line: > makec ../build/fastdebug/ test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti > JTREG="JAVA_OPTIONS=-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=1 -XX:ZFragmentationLimit=0.01" > JTREG_EXTRA_PROBLEM_LISTS=ProblemList-zgc.txt Five tests consistently asserts with this command line. All tests pass > with the proposed fix. > Recommendations of tests to run are welcome. I intend to get this run through tier1-3, but haven't yet. Notifying @reinrich @fisk since I think they have been looking into similar problems. ------------- PR: https://git.openjdk.java.net/jdk/pull/627 From stefank at openjdk.java.net Tue Oct 13 09:33:24 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 13 Oct 2020 09:33:24 GMT Subject: RFR: 8254668: JVMTI process frames on thread without started processing Message-ID: I hit the following assert in some tests runs that I've been doing: # Internal Error (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), pid=828170, tid=828734 # assert(processing_started()) failed: Processing should already have started The stack traces for this has been: Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 V [libjvm.so+0x1804c4a] vframe::sender() const+0xea V [libjvm.so+0x175f47b] JavaThread::last_java_vframe(RegisterMap*)+0x5b V [libjvm.so+0x10e10fc] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x4c V [libjvm.so+0x10e6972] JvmtiEnvBase::check_top_frame(Thread*, JavaThread*, jvalue, TosState, Handle*)+0xe2 V [libjvm.so+0x10e759c] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x11c V [libjvm.so+0x105b8f5] jvmti_ForceEarlyReturnObject+0x215 V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 V [libjvm.so+0x1804c4a] vframe::sender() const+0xea V [libjvm.so+0x1804d00] vframe::java_sender() const+0x10 V [libjvm.so+0x10e1115] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x65 V [libjvm.so+0x10d475f] JvmtiEnv::NotifyFramePop(JavaThread*, int)+0x9f V [libjvm.so+0x106b6aa] jvmti_NotifyFramePop+0x23a The code inspects the top frame of a suspended java thread. However, there's nothing in the code that starts the watermark processing of the thread, so the code asserts when sender calls on_iteration. We only have to call start_processing/on_iteration when oops are being read. The failing code does *not* inspect any oops, so I turn of the on_iteration call by settings process_frame to false. To notify the readers of the code that vframeFor doesn't process the oops, I've renamed the function to vframeForNoProcess to give a visual cue. I found this bug when running this command line: makec ../build/fastdebug/ test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti JTREG="JAVA_OPTIONS=-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=1 -XX:ZFragmentationLimit=0.01" JTREG_EXTRA_PROBLEM_LISTS=ProblemList-zgc.txt Five tests consistently asserts with this command line. All tests pass with the proposed fix. Recommendations of tests to run are welcome. I intend to get this run through tier1-3, but haven't yet. ------------- Commit messages: - 8254668: JVMTI process frames on thread without started processing Changes: https://git.openjdk.java.net/jdk/pull/627/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=627&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254668 Stats: 9 lines in 3 files changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/627/head:pull/627 PR: https://git.openjdk.java.net/jdk/pull/627 From avoitylov at openjdk.java.net Tue Oct 13 09:39:23 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Tue, 13 Oct 2020 09:39:23 GMT Subject: Integrated: JDK-8247589: Implementation of Alpine Linux/x64 Port In-Reply-To: References: Message-ID: <1UYbWcHetnzMfkPLjmtJp2XUoUdhpGmVBOkPRZ1JhqM=.56033536-ce88-45b7-8d9d-3570819bd063@github.com> On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. This pull request has now been integrated. Changeset: 63009f90 Author: Aleksei Voitylov Committer: Alexander Scherbatiy URL: https://git.openjdk.java.net/jdk/commit/63009f90 Stats: 403 lines in 30 files changed: 348 ins; 17 del; 38 mod 8247589: Implementation of Alpine Linux/x64 Port Co-authored-by: Mikael Vidstedt Co-authored-by: Alexander Scherbatiy Co-authored-by: Axel Siebenborn Co-authored-by: Aleksei Voitylov Reviewed-by: alanb, erikj, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From avoitylov at openjdk.java.net Tue Oct 13 09:54:24 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Tue, 13 Oct 2020 09:54:24 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v6] In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 06:02:04 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains three commits: >> - Merge branch 'master' into JDK-8247589 >> - JDK-8247589: Implementation of Alpine Linux/x64 Port >> - JDK-8247589: Implementation of Alpine Linux/x64 Port > > Marked as reviewed by dholmes (Reviewer). Thanks everyone! ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From eosterlund at openjdk.java.net Tue Oct 13 11:30:12 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 13 Oct 2020 11:30:12 GMT Subject: RFR: 8254668: JVMTI process frames on thread without started processing In-Reply-To: References: Message-ID: <8n43lPCxk0mlCPtfksiLfvwLAMet4xMHmdyvD8tV7m4=.5954b90b-be0d-4cbd-bcca-f57905025218@github.com> On Tue, 13 Oct 2020 09:25:55 GMT, Stefan Karlsson wrote: > I hit the following assert in some tests runs that I've been doing: > # Internal Error (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), pid=828170, > tid=828734 # assert(processing_started()) failed: Processing should already have started > > The stack traces for this has been: > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 > V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a > V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 > V [libjvm.so+0x1804c4a] vframe::sender() const+0xea > V [libjvm.so+0x175f47b] JavaThread::last_java_vframe(RegisterMap*)+0x5b > V [libjvm.so+0x10e10fc] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x4c > V [libjvm.so+0x10e6972] JvmtiEnvBase::check_top_frame(Thread*, JavaThread*, jvalue, TosState, Handle*)+0xe2 > V [libjvm.so+0x10e759c] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x11c > V [libjvm.so+0x105b8f5] jvmti_ForceEarlyReturnObject+0x215 > V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 > V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a > V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 > V [libjvm.so+0x1804c4a] vframe::sender() const+0xea > V [libjvm.so+0x1804d00] vframe::java_sender() const+0x10 > V [libjvm.so+0x10e1115] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x65 > V [libjvm.so+0x10d475f] JvmtiEnv::NotifyFramePop(JavaThread*, int)+0x9f > V [libjvm.so+0x106b6aa] jvmti_NotifyFramePop+0x23a > The code inspects the top frame of a suspended java thread. However, there's nothing in the code that starts the > watermark processing of the thread, so the code asserts when sender calls on_iteration. > We only have to call start_processing/on_iteration when oops are being read. The failing code does *not* inspect any > oops, so I turn of the on_iteration call by settings process_frame to false. > To notify the readers of the code that vframeFor doesn't process the oops, I've renamed the function to > vframeForNoProcess to give a visual cue. > I found this bug when running this command line: > makec ../build/fastdebug/ test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti > JTREG="JAVA_OPTIONS=-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=1 -XX:ZFragmentationLimit=0.01" > JTREG_EXTRA_PROBLEM_LISTS=ProblemList-zgc.txt Five tests consistently asserts with this command line. All tests pass > with the proposed fix. > Recommendations of tests to run are welcome. I intend to get this run through tier1-3, but haven't yet. Looks good. Thanks for fixing this. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/627 From rrich at openjdk.java.net Tue Oct 13 12:51:09 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 13 Oct 2020 12:51:09 GMT Subject: RFR: 8254668: JVMTI process frames on thread without started processing In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 09:25:55 GMT, Stefan Karlsson wrote: > I hit the following assert in some tests runs that I've been doing: > # Internal Error (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), pid=828170, > tid=828734 # assert(processing_started()) failed: Processing should already have started > > The stack traces for this has been: > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 > V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a > V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 > V [libjvm.so+0x1804c4a] vframe::sender() const+0xea > V [libjvm.so+0x175f47b] JavaThread::last_java_vframe(RegisterMap*)+0x5b > V [libjvm.so+0x10e10fc] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x4c > V [libjvm.so+0x10e6972] JvmtiEnvBase::check_top_frame(Thread*, JavaThread*, jvalue, TosState, Handle*)+0xe2 > V [libjvm.so+0x10e759c] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x11c > V [libjvm.so+0x105b8f5] jvmti_ForceEarlyReturnObject+0x215 > V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 > V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a > V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 > V [libjvm.so+0x1804c4a] vframe::sender() const+0xea > V [libjvm.so+0x1804d00] vframe::java_sender() const+0x10 > V [libjvm.so+0x10e1115] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x65 > V [libjvm.so+0x10d475f] JvmtiEnv::NotifyFramePop(JavaThread*, int)+0x9f > V [libjvm.so+0x106b6aa] jvmti_NotifyFramePop+0x23a > The code inspects the top frame of a suspended java thread. However, there's nothing in the code that starts the > watermark processing of the thread, so the code asserts when sender calls on_iteration. > We only have to call start_processing/on_iteration when oops are being read. The failing code does *not* inspect any > oops, so I turn of the on_iteration call by settings process_frame to false. > To notify the readers of the code that vframeFor doesn't process the oops, I've renamed the function to > vframeForNoProcess to give a visual cue. > I found this bug when running this command line: > makec ../build/fastdebug/ test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti > JTREG="JAVA_OPTIONS=-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=1 -XX:ZFragmentationLimit=0.01" > JTREG_EXTRA_PROBLEM_LISTS=ProblemList-zgc.txt Five tests consistently asserts with this command line. All tests pass > with the proposed fix. > Recommendations of tests to run are welcome. I intend to get this run through tier1-3, but haven't yet. Hi Stefan, thanks for fixing. With this change the assertion in pr #119 does not fail anymore. The fix looks good to me but I'm not an ZGC expert, neither a Reviewer :) src/hotspot/share/prims/jvmtiEnvBase.cpp line 559: > 557: > 558: // return the vframe on the specified thread and depth, NULL if no such frame > 559: // The thread and the oops in the returned might not have been process. s/the returned/the returned vframe/ ------------- Marked as reviewed by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/627 From stefank at openjdk.java.net Tue Oct 13 13:06:29 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 13 Oct 2020 13:06:29 GMT Subject: RFR: 8254668: JVMTI process frames on thread without started processing [v2] In-Reply-To: References: Message-ID: > I hit the following assert in some tests runs that I've been doing: > # Internal Error (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), pid=828170, > tid=828734 # assert(processing_started()) failed: Processing should already have started > > The stack traces for this has been: > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 > V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a > V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 > V [libjvm.so+0x1804c4a] vframe::sender() const+0xea > V [libjvm.so+0x175f47b] JavaThread::last_java_vframe(RegisterMap*)+0x5b > V [libjvm.so+0x10e10fc] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x4c > V [libjvm.so+0x10e6972] JvmtiEnvBase::check_top_frame(Thread*, JavaThread*, jvalue, TosState, Handle*)+0xe2 > V [libjvm.so+0x10e759c] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x11c > V [libjvm.so+0x105b8f5] jvmti_ForceEarlyReturnObject+0x215 > V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 > V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a > V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 > V [libjvm.so+0x1804c4a] vframe::sender() const+0xea > V [libjvm.so+0x1804d00] vframe::java_sender() const+0x10 > V [libjvm.so+0x10e1115] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x65 > V [libjvm.so+0x10d475f] JvmtiEnv::NotifyFramePop(JavaThread*, int)+0x9f > V [libjvm.so+0x106b6aa] jvmti_NotifyFramePop+0x23a > The code inspects the top frame of a suspended java thread. However, there's nothing in the code that starts the > watermark processing of the thread, so the code asserts when sender calls on_iteration. > We only have to call start_processing/on_iteration when oops are being read. The failing code does *not* inspect any > oops, so I turn of the on_iteration call by settings process_frame to false. > To notify the readers of the code that vframeFor doesn't process the oops, I've renamed the function to > vframeForNoProcess to give a visual cue. > I found this bug when running this command line: > makec ../build/fastdebug/ test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti > JTREG="JAVA_OPTIONS=-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=1 -XX:ZFragmentationLimit=0.01" > JTREG_EXTRA_PROBLEM_LISTS=ProblemList-zgc.txt Five tests consistently asserts with this command line. All tests pass > with the proposed fix. > Recommendations of tests to run are welcome. I intend to get this run through tier1-3, but haven't yet. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review 1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/627/files - new: https://git.openjdk.java.net/jdk/pull/627/files/587fd354..00c1b25f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=627&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=627&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/627/head:pull/627 PR: https://git.openjdk.java.net/jdk/pull/627 From stefank at openjdk.java.net Tue Oct 13 13:06:30 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 13 Oct 2020 13:06:30 GMT Subject: RFR: 8254668: JVMTI process frames on thread without started processing [v2] In-Reply-To: References: Message-ID: <3dSL6O7WvOI3GBrnN9vB_wZgq-XE1S6vihRUhsnBUgs=.1e159afe-891c-4fa4-8d40-9da2e2a3cd4a@github.com> On Tue, 13 Oct 2020 12:48:05 GMT, Richard Reingruber wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review 1 > > Hi Stefan, > > thanks for fixing. > > With this change the assertion in pr #119 does not fail anymore. > > The fix looks good to me but I'm not an ZGC expert, neither a Reviewer :) Thanks @fisk and @reinrich for reviewing. > src/hotspot/share/prims/jvmtiEnvBase.cpp line 559: > >> 557: >> 558: // return the vframe on the specified thread and depth, NULL if no such frame >> 559: // The thread and the oops in the returned might not have been process. > > s/the returned/the returned vframe/ Thanks for noticing. ------------- PR: https://git.openjdk.java.net/jdk/pull/627 From amenkov at openjdk.java.net Tue Oct 13 16:42:14 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 13 Oct 2020 16:42:14 GMT Subject: RFR: 8249623: test @ignore-d due to 7013634 should be returned back to =?UTF-8?B?ZXhl4oCm?= In-Reply-To: References: Message-ID: On Wed, 7 Oct 2020 20:07:56 GMT, Alex Menkov wrote: > - updated timeout/stressTime for resexhausted001 test so on Windows we get "can't reproduce OOME" instead of timeout; > - updated resexhausted001 cleanup code (to terminate all threads); > - intermittent resexhausted001 failure on linux is problem-listed; > - updated resexhausted001 and resexhausted002 to throw SkippedException if OOM is not thrown Ping ------------- PR: https://git.openjdk.java.net/jdk/pull/551 From rrich at openjdk.java.net Tue Oct 13 17:13:24 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 13 Oct 2020 17:13:24 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v9] In-Reply-To: References: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com> Message-ID: On Sun, 11 Oct 2020 07:20:07 GMT, Richard Reingruber wrote: >>> >>> >>> I tried to run testing with latest changes and latest JDK and build failed: >>> src/hotspot/share/runtime/escapeBarrier.cpp:310:35: error: no matching function for call to >>> 'StackFrameStream::StackFrameStream(JavaThread*&)' 310 | StackFrameStream fst(deoptee); >> >> I noticed this too. I wanted to test with ZGC before pushing the small >> fix. Unfortunately I get >> >> # Internal Error (/priv/d038402/git/reinrich/jdk_ea_new/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), >> pid=90890, tid=90912 # assert(processing_started()) failed: Processing should already have started >> >> [...] >> >> Current thread (0x00007f749c25b1c0): JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_vm, id=90912, >> stack(0x00007f7474c9f000,0x00007f7474da0000)] _threads_hazard_ptr=0x00007f749c2b00c0, _nested_threads_hazard_ptr_cnt=0 >> Stack: [0x00007f7474c9f000,0x00007f7474da0000], sp=0x00007f7474d9c240, free space=1012k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x15b3255] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xa5 >> V [libjvm.so+0xa1024f] frame::sender(RegisterMap*) const+0x13f >> V [libjvm.so+0xa048f8] frame::real_sender(RegisterMap*) const+0x18 >> V [libjvm.so+0x176261b] vframe::sender() const+0xeb >> V [libjvm.so+0x16cd56b] JavaThread::last_java_vframe(RegisterMap*)+0x5b >> V [libjvm.so+0xfa7a56] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x46 >> V [libjvm.so+0xfab8e5] JvmtiEnvBase::check_top_frame(JavaThread*, JavaThread*, jvalue, TosState, Handle*)+0x1f5 >> V [libjvm.so+0xfac13e] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x15e >> V [libjvm.so+0xf36fa8] jvmti_ForceEarlyReturnLong+0x258 >> C [libjdwp.so+0xa8b3] forceEarlyReturn+0x293 >> C [libjdwp.so+0x12945] debugLoop_run+0x1f5 >> C [libjdwp.so+0x25bb3] attachThread+0x33 >> V [libjvm.so+0xfcf524] JvmtiAgentThread::call_start_function()+0x1d4 >> V [libjvm.so+0x16cc8f7] JavaThread::thread_main_inner()+0x247 >> V [libjvm.so+0x16d1ce8] Thread::call_run()+0xf8 >> V [libjvm.so+0x12dd75e] thread_native_entry(Thread*)+0x10e >> >> In the test case >> `EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure` of the >> new test `jdk/com/sun/jdi/EATests.java` >> >> So far I do not have an indication that the failure is caused by this change but >> when I run the test with -XX:-DoEscapeAnalysis then the test succeeds. >> >> I need to look more into it. Wish I was a ZGC expert :) >> >> Anyway I pushed the build fix. Tests succeed with default GC. > > The crash described above happens after JDK-8253180 > (https://github.com/openjdk/jdk/commit/b9873e18330b7e43ca47bc1c0655e7ab20828f7a) when executing `EATests.java` with > ZGC: make run-test TEST=test/jdk/com/sun/jdi/EATests.java JTREG=VM_OPTIONS=-XX:+UseZGC > > My understanding of JDK-8253180 (and ZGC) is rather vague. To me it looks as if stackwalks outside of a > safepoint/handshake on suspended threads are currently not supported. It would be my understanding that > `StackWatermarkSet::start_processing()` needs to be called before walking the stack of a thread. Currently this is only > done in preparation of a safepoint or handshake. `JvmtiEnvBase::check_top_frame()` walks the stack of a suspended > thread without safepoint/handshake. This triggers the crash in my opinion. When `StackWatermarkSet::start_processing()` > is called before the test succeeds. I will ask Erik ?sterlund about this. The issues with ZGC concurrent thread stack processing will be resolved with #627 ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From cjplummer at openjdk.java.net Tue Oct 13 18:03:14 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 13 Oct 2020 18:03:14 GMT Subject: RFR: 8249623: test @ignore-d due to 7013634 should be returned back to =?UTF-8?B?ZXhl4oCm?= In-Reply-To: References: Message-ID: <7PNUYRqxlN7iPe2QVLSJlWPXph7TYEyFON-4hl6kxQ4=.0574c948-c61e-4970-aa00-695d86e1c643@github.com> On Wed, 7 Oct 2020 20:07:56 GMT, Alex Menkov wrote: > - updated timeout/stressTime for resexhausted001 test so on Windows we get "can't reproduce OOME" instead of timeout; > - updated resexhausted001 cleanup code (to terminate all threads); > - intermittent resexhausted001 failure on linux is problem-listed; > - updated resexhausted001 and resexhausted002 to throw SkippedException if OOM is not thrown Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/551 From kvn at openjdk.java.net Wed Oct 14 00:28:23 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 14 Oct 2020 00:28:23 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v10] In-Reply-To: References: Message-ID: On Sat, 10 Oct 2020 08:34:23 GMT, Richard Reingruber wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 21 commits: > - The constructor of StackFrameStream takes more parameters after JDK-8253180 > - Merge branch 'master' into JDK-8227745 > - Merge branch 'master' into JDK-8227745 > - Merge branch 'master' into JDK-8227745 > - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame. > - More smaller changes proposed by Serguei. > - jvmtiDeferredUpdates.hpp: remove forward declarations. > - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition. > - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation. > - Merge branch 'master' into JDK-8227745 > - ... and 11 more: https://git.openjdk.java.net/jdk/compare/aaa0a2a0...06b139a9 Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/119 From sspitsyn at openjdk.java.net Wed Oct 14 01:23:11 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 14 Oct 2020 01:23:11 GMT Subject: RFR: 8249623: test @ignore-d due to 7013634 should be returned back to =?UTF-8?B?ZXhl4oCm?= In-Reply-To: References: Message-ID: On Wed, 7 Oct 2020 20:07:56 GMT, Alex Menkov wrote: > - updated timeout/stressTime for resexhausted001 test so on Windows we get "can't reproduce OOME" instead of timeout; > - updated resexhausted001 cleanup code (to terminate all threads); > - intermittent resexhausted001 failure on linux is problem-listed; > - updated resexhausted001 and resexhausted002 to throw SkippedException if OOM is not thrown Hi Alex, Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/551 From stefank at openjdk.java.net Wed Oct 14 10:32:16 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 14 Oct 2020 10:32:16 GMT Subject: Integrated: 8254668: JVMTI process frames on thread without started processing In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 09:25:55 GMT, Stefan Karlsson wrote: > I hit the following assert in some tests runs that I've been doing: > # Internal Error (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), pid=828170, > tid=828734 # assert(processing_started()) failed: Processing should already have started > > The stack traces for this has been: > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 > V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a > V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 > V [libjvm.so+0x1804c4a] vframe::sender() const+0xea > V [libjvm.so+0x175f47b] JavaThread::last_java_vframe(RegisterMap*)+0x5b > V [libjvm.so+0x10e10fc] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x4c > V [libjvm.so+0x10e6972] JvmtiEnvBase::check_top_frame(Thread*, JavaThread*, jvalue, TosState, Handle*)+0xe2 > V [libjvm.so+0x10e759c] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x11c > V [libjvm.so+0x105b8f5] jvmti_ForceEarlyReturnObject+0x215 > V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5 > V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a > V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18 > V [libjvm.so+0x1804c4a] vframe::sender() const+0xea > V [libjvm.so+0x1804d00] vframe::java_sender() const+0x10 > V [libjvm.so+0x10e1115] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x65 > V [libjvm.so+0x10d475f] JvmtiEnv::NotifyFramePop(JavaThread*, int)+0x9f > V [libjvm.so+0x106b6aa] jvmti_NotifyFramePop+0x23a > The code inspects the top frame of a suspended java thread. However, there's nothing in the code that starts the > watermark processing of the thread, so the code asserts when sender calls on_iteration. > We only have to call start_processing/on_iteration when oops are being read. The failing code does *not* inspect any > oops, so I turn of the on_iteration call by settings process_frame to false. > To notify the readers of the code that vframeFor doesn't process the oops, I've renamed the function to > vframeForNoProcess to give a visual cue. > I found this bug when running this command line: > makec ../build/fastdebug/ test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti > JTREG="JAVA_OPTIONS=-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=1 -XX:ZFragmentationLimit=0.01" > JTREG_EXTRA_PROBLEM_LISTS=ProblemList-zgc.txt Five tests consistently asserts with this command line. All tests pass > with the proposed fix. > Recommendations of tests to run are welcome. I intend to get this run through tier1-3, but haven't yet. This pull request has now been integrated. Changeset: db9dcdf1 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/db9dcdf1 Stats: 9 lines in 3 files changed: 1 ins; 0 del; 8 mod 8254668: JVMTI process frames on thread without started processing Reviewed-by: eosterlund, rrich ------------- PR: https://git.openjdk.java.net/jdk/pull/627 From shade at openjdk.java.net Wed Oct 14 14:58:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Oct 2020 14:58:20 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics Message-ID: This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to `Instrumentation`, and let the tools use that fast path today. With this patch, JOL is able to be close to `deepSizeOf` implementation from SizeOf JEP. Example performance improvements for sizing up a custom linked list: Benchmark (size) Mode Cnt Score Error Units # Default LinkedChainBench.linkedChain 1 avgt 5 705.835 ? 8.051 ns/op LinkedChainBench.linkedChain 10 avgt 5 3148.874 ? 37.856 ns/op LinkedChainBench.linkedChain 100 avgt 5 28693.256 ? 142.254 ns/op LinkedChainBench.linkedChain 1000 avgt 5 290161.590 ? 4594.631 ns/op # Instrumentation attached, no intrinsics LinkedChainBench.linkedChain 1 avgt 5 159.659 ? 19.238 ns/op LinkedChainBench.linkedChain 10 avgt 5 717.659 ? 22.540 ns/op LinkedChainBench.linkedChain 100 avgt 5 7739.394 ? 111.683 ns/op LinkedChainBench.linkedChain 1000 avgt 5 80724.238 ? 2887.794 ns/op # Instrumentation attached, new intrinsics LinkedChainBench.linkedChain 1 avgt 5 95.254 ? 0.808 ns/op LinkedChainBench.linkedChain 10 avgt 5 261.564 ? 8.524 ns/op LinkedChainBench.linkedChain 100 avgt 5 3367.192 ? 21.128 ns/op LinkedChainBench.linkedChain 1000 avgt 5 34148.851 ? 373.080 ns/op ------------- Commit messages: - 8253525: Implement getInstanceSize/sizeOf intrinsics Changes: https://git.openjdk.java.net/jdk/pull/650/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253525 Stats: 613 lines in 10 files changed: 564 ins; 0 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/650.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/650/head:pull/650 PR: https://git.openjdk.java.net/jdk/pull/650 From shade at openjdk.java.net Wed Oct 14 15:10:23 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Oct 2020 15:10:23 GMT Subject: RFR: 8254777: Remove unimplemented Management::get_loaded_classes Message-ID: There seems to be no definition of `Management::get_loaded_classes` anywhere in current tip or history prior the initial load. Can be removed. Testing: - [x] Linux x86_64 build - [x] Text search for `get_loaded_classes` in `src/hotspot` ------------- Commit messages: - 8254777: Remove unimplemented Management::get_loaded_classes Changes: https://git.openjdk.java.net/jdk/pull/660/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=660&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254777 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/660.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/660/head:pull/660 PR: https://git.openjdk.java.net/jdk/pull/660 From shade at openjdk.java.net Wed Oct 14 15:25:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Oct 2020 15:25:20 GMT Subject: RFR: 8254780: EnterInterpOnlyModeClosure::completed() always returns true Message-ID: JDK-8238761 introduced this funky code: class EnterInterpOnlyModeClosure : public HandshakeClosure { private: bool _completed; public: EnterInterpOnlyModeClosure() : HandshakeClosure("EnterInterpOnlyMode"), _completed(false) { } void do_thread(Thread* th) { ... _completed = true; } bool completed() { return _completed = true; } }; It seems the flag is there to communicate that target thread indeed executed the handshake. But `completed()` sets the bool unconditionally and always returns true. And it is used in one and only place here: guarantee(hs.completed(), "Handshake failed: Target thread is not alive?"); ...which means that guarantee always passes. Attention @robehn :) ------------- Commit messages: - 8254780: EnterInterpOnlyModeClosure::completed() always returns true Changes: https://git.openjdk.java.net/jdk/pull/662/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=662&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254780 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/662.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/662/head:pull/662 PR: https://git.openjdk.java.net/jdk/pull/662 From shade at openjdk.java.net Wed Oct 14 15:39:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Oct 2020 15:39:20 GMT Subject: RFR: 8254781: Remove unimplemented ClassFieldMap::compute_field_count Message-ID: There is no definition of `ClassFieldMap::compute_field_count` in current tip or any history after the initial load. Can be removed. Testing: - [x] Linux x86_64 build - [x] Text searches for `compute_field_count` in `src/hotspot` ------------- Commit messages: - 8254781: Remove unimplemented ClassFieldMap::compute_field_count Changes: https://git.openjdk.java.net/jdk/pull/663/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=663&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254781 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/663/head:pull/663 PR: https://git.openjdk.java.net/jdk/pull/663 From phh at openjdk.java.net Wed Oct 14 15:45:17 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Wed, 14 Oct 2020 15:45:17 GMT Subject: RFR: 8254781: Remove unimplemented ClassFieldMap::compute_field_count In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 15:27:26 GMT, Aleksey Shipilev wrote: > There is no definition of `ClassFieldMap::compute_field_count` in current tip or any history after the initial load. > Can be removed. > Testing: > - [x] Linux x86_64 build > - [x] Text searches for `compute_field_count` in `src/hotspot` Marked as reviewed by phh (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/663 From sspitsyn at openjdk.java.net Wed Oct 14 17:18:16 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 14 Oct 2020 17:18:16 GMT Subject: RFR: 8254777: Remove unimplemented Management::get_loaded_classes In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 15:04:32 GMT, Aleksey Shipilev wrote: > There seems to be no definition of `Management::get_loaded_classes` anywhere in current tip or history prior the > initial load. Can be removed. > Testing: > - [x] Linux x86_64 build > - [x] Text search for `get_loaded_classes` in `src/hotspot` Hi Aleksey, This is good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/660 From sspitsyn at openjdk.java.net Wed Oct 14 17:23:08 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 14 Oct 2020 17:23:08 GMT Subject: RFR: 8254780: EnterInterpOnlyModeClosure::completed() always returns true In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 15:16:54 GMT, Aleksey Shipilev wrote: > JDK-8238761 introduced this funky code: > > class EnterInterpOnlyModeClosure : public HandshakeClosure { > private: > bool _completed; > public: > EnterInterpOnlyModeClosure() : HandshakeClosure("EnterInterpOnlyMode"), _completed(false) { } > void do_thread(Thread* th) { > ... > _completed = true; > } > bool completed() { > return _completed = true; > } > }; > > It seems the flag is there to communicate that target thread indeed executed the handshake. But `completed()` sets the > bool unconditionally and always returns true. And it is used in one and only place here: > guarantee(hs.completed(), "Handshake failed: Target thread is not alive?"); > > ...which means that guarantee always passes. > > Attention @robehn :) It looks good. Thank you for catching and fixing it! Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/662 From sspitsyn at openjdk.java.net Wed Oct 14 17:27:20 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 14 Oct 2020 17:27:20 GMT Subject: RFR: 8254781: Remove unimplemented ClassFieldMap::compute_field_count In-Reply-To: References: Message-ID: <430N-0bDu4Jg7qzWLztx_SZiXp1NkrWEKRiFoIWgPjY=.4fcd1173-e834-471b-9fbc-3419fe91f236@github.com> On Wed, 14 Oct 2020 15:27:26 GMT, Aleksey Shipilev wrote: > There is no definition of `ClassFieldMap::compute_field_count` in current tip or any history after the initial load. > Can be removed. > Testing: > - [x] Linux x86_64 build > - [x] Text searches for `compute_field_count` in `src/hotspot` It looks good and trivial. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/663 From amenkov at openjdk.java.net Wed Oct 14 17:49:16 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 14 Oct 2020 17:49:16 GMT Subject: Integrated: 8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly In-Reply-To: <-d8IM-dOKNuxCl-f4xc-FQFWxeIxh0bkqnJx2LreaGU=.d03bda3d-b015-43de-a597-e9964c74cf33@github.com> References: <-d8IM-dOKNuxCl-f4xc-FQFWxeIxh0bkqnJx2LreaGU=.d03bda3d-b015-43de-a597-e9964c74cf33@github.com> Message-ID: On Mon, 12 Oct 2020 21:03:55 GMT, Alex Menkov wrote: > Please review a trivial fix for JdwpAttachTest This pull request has now been integrated. Changeset: b7daf842 Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/b7daf842 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/619 From amenkov at openjdk.java.net Wed Oct 14 17:54:18 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 14 Oct 2020 17:54:18 GMT Subject: Integrated: 8249623: test @ignore-d due to 7013634 should be returned back to execution In-Reply-To: References: Message-ID: On Wed, 7 Oct 2020 20:07:56 GMT, Alex Menkov wrote: > - updated timeout/stressTime for resexhausted001 test so on Windows we get "can't reproduce OOME" instead of timeout; > - updated resexhausted001 cleanup code (to terminate all threads); > - intermittent resexhausted001 failure on linux is problem-listed; > - updated resexhausted001 and resexhausted002 to throw SkippedException if OOM is not thrown This pull request has now been integrated. Changeset: cd33abb1 Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/cd33abb1 Stats: 12 lines in 4 files changed: 4 ins; 2 del; 6 mod 8249623: test @ignore-d due to 7013634 should be returned back to execution Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/551 From rehn at openjdk.java.net Wed Oct 14 18:52:09 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Oct 2020 18:52:09 GMT Subject: RFR: 8254780: EnterInterpOnlyModeClosure::completed() always returns true In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 15:16:54 GMT, Aleksey Shipilev wrote: > JDK-8238761 introduced this funky code: > > class EnterInterpOnlyModeClosure : public HandshakeClosure { > private: > bool _completed; > public: > EnterInterpOnlyModeClosure() : HandshakeClosure("EnterInterpOnlyMode"), _completed(false) { } > void do_thread(Thread* th) { > ... > _completed = true; > } > bool completed() { > return _completed = true; > } > }; > > It seems the flag is there to communicate that target thread indeed executed the handshake. But `completed()` sets the > bool unconditionally and always returns true. And it is used in one and only place here: > guarantee(hs.completed(), "Handshake failed: Target thread is not alive?"); > > ...which means that guarantee always passes. > > Attention @robehn :) My bad, thanks @shipilev ! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/662 From ccheung at openjdk.java.net Wed Oct 14 20:45:17 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 14 Oct 2020 20:45:17 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v3] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Tue, 13 Oct 2020 06:46:27 GMT, Ioi Lam wrote: >> **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in >> memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each >> of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert >> to fail. >> >> **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to >> access each individual cloned vtable. >> >> **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just >> do the bare minimum to fix the bug, it will be pretty hard to review. >> >> I would suggest that the reviewers look at just the new version of the code and see if it's working as described >> (instead of looking at the diff to understand what the bug was and how it has been fixed). >> This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. >> I plan to change that into templates in a future RFE. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes > the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last > revision: > - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 > - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) > - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 > - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From rrich at openjdk.java.net Wed Oct 14 20:53:15 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 14 Oct 2020 20:53:15 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v10] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 00:25:14 GMT, Vladimir Kozlov wrote: > > > Good. Thanks for the review, Vladimir (@vnkozlov)! I'm still (stress) testing adaptations to lazy/concurrent thread stack processing for ZGC. --Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From shade at openjdk.java.net Wed Oct 14 21:00:17 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Oct 2020 21:00:17 GMT Subject: Integrated: 8254781: Remove unimplemented ClassFieldMap::compute_field_count In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 15:27:26 GMT, Aleksey Shipilev wrote: > There is no definition of `ClassFieldMap::compute_field_count` in current tip or any history after the initial load. > Can be removed. > Testing: > - [x] Linux x86_64 build > - [x] Text searches for `compute_field_count` in `src/hotspot` This pull request has now been integrated. Changeset: 8fb294a2 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/8fb294a2 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8254781: Remove unimplemented ClassFieldMap::compute_field_count Reviewed-by: phh, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/663 From shade at openjdk.java.net Wed Oct 14 21:01:17 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Oct 2020 21:01:17 GMT Subject: Integrated: 8254780: EnterInterpOnlyModeClosure::completed() always returns true In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 15:16:54 GMT, Aleksey Shipilev wrote: > JDK-8238761 introduced this funky code: > > class EnterInterpOnlyModeClosure : public HandshakeClosure { > private: > bool _completed; > public: > EnterInterpOnlyModeClosure() : HandshakeClosure("EnterInterpOnlyMode"), _completed(false) { } > void do_thread(Thread* th) { > ... > _completed = true; > } > bool completed() { > return _completed = true; > } > }; > > It seems the flag is there to communicate that target thread indeed executed the handshake. But `completed()` sets the > bool unconditionally and always returns true. And it is used in one and only place here: > guarantee(hs.completed(), "Handshake failed: Target thread is not alive?"); > > ...which means that guarantee always passes. > > Attention @robehn :) This pull request has now been integrated. Changeset: da2f5ab5 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/da2f5ab5 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8254780: EnterInterpOnlyModeClosure::completed() always returns true Reviewed-by: sspitsyn, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/662 From shade at openjdk.java.net Wed Oct 14 21:02:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Oct 2020 21:02:10 GMT Subject: Integrated: 8254777: Remove unimplemented Management::get_loaded_classes In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 15:04:32 GMT, Aleksey Shipilev wrote: > There seems to be no definition of `Management::get_loaded_classes` anywhere in current tip or history prior the > initial load. Can be removed. > Testing: > - [x] Linux x86_64 build > - [x] Text search for `get_loaded_classes` in `src/hotspot` This pull request has now been integrated. Changeset: 03fa733e Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/03fa733e Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8254777: Remove unimplemented Management::get_loaded_classes Reviewed-by: sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/660 From iklam at openjdk.java.net Wed Oct 14 21:03:19 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Oct 2020 21:03:19 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v3] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: <9Fbnbx_4a92wcpClyKUiFIUON2Za2LzA4WFbRfKQOuI=.764816a4-0c9f-4168-9b46-f7f4f810eddc@github.com> On Wed, 14 Oct 2020 20:42:44 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes >> the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last >> revision: >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 >> - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) >> - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 >> - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows > > Marked as reviewed by ccheung (Reviewer). > In the function `ArchiveBuilder::gather_klass_and_symbol(MetaspaceClosure::Ref* ref, bool read_only)` > Instead of `BytesPerWord`, is `BytesPerInt` more appropriate since the `ref->size()` returns an int? Hi Calvin, thanks for the review. For the line `int bytes = ref->size() * BytesPerWord;`, `ref->size()` has the same API as all the `size()` methods of the `MetaspaceObj` classes. I.e., "the number of words needed to hold this object". That's why we need to multiple by `BytesPerWord` to calculate the number of bytes needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From amenkov at openjdk.java.net Wed Oct 14 22:33:16 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 14 Oct 2020 22:33:16 GMT Subject: RFR: 6606767: resexhausted00[34] fail assert(!thread->owns_locks(), "must release all locks when leaving VM") Message-ID: Please review the fix for JDK-6606767. The original issue is not reproducible. The fix: - resexhausted003 and resexhausted004 are un-problemlisted - resexhausted004 is problemlisted on linux due JDK-8253916 (resexhausted004 executes resexhausted001/resexhausted002/resexhausted003 randomly, and resexhausted001 fails on linux) - resexhausted003 is updated to throw SkippedException if OOME is not thrown; - resexhausted004 is updated to catch SkippedException from resexhausted001..003, also logic is slightly simplified ------------- Commit messages: - 6606767: resexhausted00[34] fail assert(!thread->owns_locks(), "must release all locks when leaving VM") Changes: https://git.openjdk.java.net/jdk/pull/671/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=671&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6606767 Stats: 21 lines in 3 files changed: 9 ins; 7 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/671/head:pull/671 PR: https://git.openjdk.java.net/jdk/pull/671 From sspitsyn at openjdk.java.net Wed Oct 14 23:17:11 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 14 Oct 2020 23:17:11 GMT Subject: RFR: 6606767: resexhausted00[34] fail assert(!thread->owns_locks(), "must release all locks when leaving VM") In-Reply-To: References: Message-ID: <5eGoCCw6xA3C1vxsAFE0OyVyYF4HJecZXgfYKbTSABI=.0fa297d4-6b06-496f-b6ae-b0fc677ead9e@github.com> On Wed, 14 Oct 2020 22:25:34 GMT, Alex Menkov wrote: > Please review the fix for JDK-6606767. > The original issue is not reproducible. > The fix: > - resexhausted003 and resexhausted004 are un-problemlisted > - resexhausted004 is problemlisted on linux due JDK-8253916 (resexhausted004 executes > resexhausted001/resexhausted002/resexhausted003 randomly, and resexhausted001 fails on linux) > - resexhausted003 is updated to throw SkippedException if OOME is not thrown; > - resexhausted004 is updated to catch SkippedException from resexhausted001..003, also logic is slightly simplified Hi Alex, I'm okay with this fix. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/671 From iignatyev at openjdk.java.net Thu Oct 15 22:56:18 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 15 Oct 2020 22:56:18 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb Message-ID: Hi all, could you please review this patch which reformats/cleans up the code of vmTestbase/nsk/jdb tests? the part of this patch is a spinoff from #350. testing: * [x] `vmTestbase/nsk/jdb` tests on `linux-x64-debug` ------------- Commit messages: - 8254861: reformat code in vmTestbase/nsk/jdb Changes: https://git.openjdk.java.net/jdk/pull/689/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=689&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254861 Stats: 3829 lines in 130 files changed: 572 ins; 489 del; 2768 mod Patch: https://git.openjdk.java.net/jdk/pull/689.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/689/head:pull/689 PR: https://git.openjdk.java.net/jdk/pull/689 From iignatyev at openjdk.java.net Thu Oct 15 23:25:25 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 15 Oct 2020 23:25:25 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: > Hi all, > > could you please review this patch which reformats/cleans up the code of vmTestbase/nsk/jdb tests? > > the part of this patch is a spinoff from #350. > > testing: > * [x] `vmTestbase/nsk/jdb` tests on `linux-x64-debug` Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: update copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/689/files - new: https://git.openjdk.java.net/jdk/pull/689/files/1b6fa98f..e43129d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=689&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=689&range=00-01 Stats: 64 lines in 64 files changed: 0 ins; 0 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/689.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/689/head:pull/689 PR: https://git.openjdk.java.net/jdk/pull/689 From iklam at openjdk.java.net Fri Oct 16 05:18:32 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 16 Oct 2020 05:18:32 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v4] In-Reply-To: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: > **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in > memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each > of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert > to fail. > > **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to > access each individual cloned vtable. > > **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just > do the bare minimum to fix the bug, it will be pretty hard to review. > > I would suggest that the reviewers look at just the new version of the code and see if it's working as described > (instead of looking at the diff to understand what the bug was and how it has been fixed). > This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. > I plan to change that into templates in a future RFE. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/591/files - new: https://git.openjdk.java.net/jdk/pull/591/files/5002b820..9261bfb1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=02-03 Stats: 302206 lines in 574 files changed: 296331 ins; 3612 del; 2263 mod Patch: https://git.openjdk.java.net/jdk/pull/591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/591/head:pull/591 PR: https://git.openjdk.java.net/jdk/pull/591 From iklam at openjdk.java.net Fri Oct 16 05:18:33 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 16 Oct 2020 05:18:33 GMT Subject: Integrated: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows In-Reply-To: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: <8KNbTYSEgII2zIqwF7TKHP6cPq2h-qsva6NfGcqtrv0=.3924d3f7-f5b0-4603-aac2-b4698955b631@github.com> On Sun, 11 Oct 2020 04:04:56 GMT, Ioi Lam wrote: > **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in > memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each > of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert > to fail. > > **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to > access each individual cloned vtable. > > **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just > do the bare minimum to fix the bug, it will be pretty hard to review. > > I would suggest that the reviewers look at just the new version of the code and see if it's working as described > (instead of looking at the diff to understand what the bug was and how it has been fixed). > This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. > I plan to change that into templates in a future RFE. This pull request has now been integrated. Changeset: 5145bed0 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/5145bed0 Stats: 172 lines in 11 files changed: 33 ins; 63 del; 76 mod 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows Reviewed-by: shade, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From rrich at openjdk.java.net Fri Oct 16 12:08:27 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 16 Oct 2020 12:08:27 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v11] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Removed unused parameter from EscapeBarrierSuspendHandshake. - Adaptations to JDK-8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() With JDK-8254263 the special_runtime_exit_condition() check was removed from ~ThreadInVMForHandshake() because now a thread never becomes unsafe when processing its own handshakes. EscapeBarrier uses handshakes to sync with the target thread for object deoptimization so we add a check for object deoptimization to ThreadSafepointState::handle_polling_page_exception(). In JavaThread::wait_for_object_deoptimization() we must check is_obj_deopt_suspend() again after handshake/safepoint processing because a handshake for obj. deopt suspend could have been processed. - Adaptions to lazy/concurrent thread stack processing for ZGC (JEP 376) - EATests.java improvements - Merge branch 'master' into JDK-8227745 - The constructor of StackFrameStream takes more parameters after JDK-8253180 - Merge branch 'master' into JDK-8227745 - Merge branch 'master' into JDK-8227745 - Merge branch 'master' into JDK-8227745 - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame. - ... and 16 more: https://git.openjdk.java.net/jdk/compare/9359ff03...f02f07b6 ------------- Changes: https://git.openjdk.java.net/jdk/pull/119/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=10 Stats: 5863 lines in 53 files changed: 5645 ins; 116 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From stefank at openjdk.java.net Fri Oct 16 14:39:20 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 16 Oct 2020 14:39:20 GMT Subject: RFR: 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing Message-ID: The cm03t001 test creates a local JNI handle in the prepare function. It later uses that handle from a callback function, from another thread. When the callback runs, ZGC applies a load barrier to that handle and self-heals it in the other threads stack. Later when that thread verifies its stack, during the start of its stack processing, it finds that the oop is unexpectedly not "bad". It's invalid to send a local JNI handle over to another thread: https://docs.oracle.com/en/java/javase/15/docs/specs/jni/design.html#global-and-local-references So, my proposed fix is to convert the local handle to a global handle. I've tested this with the reproducer in the bug report. ------------- Commit messages: - 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing Changes: https://git.openjdk.java.net/jdk/pull/701/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=701&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254874 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/701.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/701/head:pull/701 PR: https://git.openjdk.java.net/jdk/pull/701 From tschatzl at openjdk.java.net Fri Oct 16 15:42:11 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 16 Oct 2020 15:42:11 GMT Subject: RFR: 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing In-Reply-To: References: Message-ID: <5of6FXvXOiekGvpx0PshNlchjw8rrZIRGVEPFLvaQFY=.bf4bc4f5-213d-4bf1-8824-297f5297e4ca@github.com> On Fri, 16 Oct 2020 14:29:46 GMT, Stefan Karlsson wrote: > The cm03t001 test creates a local JNI handle in the prepare function. It later uses that handle from a callback > function, from another thread. When the callback runs, ZGC applies a load barrier to that handle and self-heals it in > the other threads stack. Later when that thread verifies its stack, during the start of its stack processing, it finds > that the oop is unexpectedly not "bad". It's invalid to send a local JNI handle over to another thread: > https://docs.oracle.com/en/java/javase/15/docs/specs/jni/design.html#global-and-local-references > So, my proposed fix is to convert the local handle to a global handle. > > I've tested this with the reproducer in the bug report. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/701 From cjplummer at openjdk.java.net Fri Oct 16 16:16:12 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 16 Oct 2020 16:16:12 GMT Subject: RFR: 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 14:29:46 GMT, Stefan Karlsson wrote: > The cm03t001 test creates a local JNI handle in the prepare function. It later uses that handle from a callback > function, from another thread. When the callback runs, ZGC applies a load barrier to that handle and self-heals it in > the other threads stack. Later when that thread verifies its stack, during the start of its stack processing, it finds > that the oop is unexpectedly not "bad". It's invalid to send a local JNI handle over to another thread: > https://docs.oracle.com/en/java/javase/15/docs/specs/jni/design.html#global-and-local-references > So, my proposed fix is to convert the local handle to a global handle. > > I've tested this with the reproducer in the bug report. The changes look good. It is confusing however that klass is also a local variable in a few functions, hiding the static version from scope, but this is a pre-existing problem. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/701 From sspitsyn at openjdk.java.net Fri Oct 16 16:52:18 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 16 Oct 2020 16:52:18 GMT Subject: RFR: 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 14:29:46 GMT, Stefan Karlsson wrote: > The cm03t001 test creates a local JNI handle in the prepare function. It later uses that handle from a callback > function, from another thread. When the callback runs, ZGC applies a load barrier to that handle and self-heals it in > the other threads stack. Later when that thread verifies its stack, during the start of its stack processing, it finds > that the oop is unexpectedly not "bad". It's invalid to send a local JNI handle over to another thread: > https://docs.oracle.com/en/java/javase/15/docs/specs/jni/design.html#global-and-local-references > So, my proposed fix is to convert the local handle to a global handle. > > I've tested this with the reproducer in the bug report. Hi Stefan, The fix looks good. Thank you for catching this. The test has 4 more static variables which are not used in the events handlers. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/701 From mgronlun at openjdk.java.net Fri Oct 16 22:42:17 2020 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 16 Oct 2020 22:42:17 GMT Subject: RFR: 8243962: Various JVM TI tests time out using JFR on Windows Message-ID: Greetings, JDK-8243962 has been a large effort to chase down intermittent timeouts for certain JVMTI tests when run on Windows debug builds in combination with JFR. The background is long, included in JDK-8243962. In short, the combination of some JVMTI thread suspension tests when run together with JFR on saturated Windows 2016 debug builds can intermittently time out. There have been two major changes made to JFR derived from JDK-8243962 (linked therein) in an attempt to reduce the poor scalability observed. Unfortunately, the efforts have not fully resolved the situation entirely as there have still been intermittent sightings for the following tests: vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/TestDescription.java vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/TestDescription.java vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/TestDescription.java vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/TestDescription.java This change will add a requires expression to these tests to exclude the combination of running them with JFR on Windows debug builds. Thanks Markus ------------- Commit messages: - 8243962: Various JVM TI tests time out using JFR on Windows Changes: https://git.openjdk.java.net/jdk/pull/712/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=712&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243962 Stats: 8 lines in 4 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/712/head:pull/712 PR: https://git.openjdk.java.net/jdk/pull/712 From sspitsyn at openjdk.java.net Fri Oct 16 23:31:12 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 16 Oct 2020 23:31:12 GMT Subject: RFR: 8243962: Various JVM TI tests time out using JFR on Windows In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 22:30:14 GMT, Markus Gr?nlund wrote: > Greetings, > > JDK-8243962 has been a large effort to chase down intermittent timeouts for certain JVMTI tests when run on Windows > debug builds in combination with JFR. The background is long, included in JDK-8243962. > In short, the combination of some JVMTI thread suspension tests when run together with JFR on saturated Windows 2016 > debug builds can intermittently time out. > There have been two major changes made to JFR derived from JDK-8243962 (linked therein) in an attempt to reduce the > poor scalability observed. > Unfortunately, the efforts have not fully resolved the situation entirely as there have still been intermittent > sightings for the following tests: > vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/TestDescription.java > vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/TestDescription.java > vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/TestDescription.java > vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/TestDescription.java > > This change will add a requires expression to these tests to exclude the combination of running them with JFR on > Windows debug builds. > Thanks > Markus Hi Markus, I'd suggest to simplify the requires statement from: + * @requires !vm.flightRecorder | !(vm.debug & os.family == "windows") to: + * @requires !vm.flightRecorder | !vm.debug | os.family != "windows" Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/712 From cjplummer at openjdk.java.net Fri Oct 16 23:50:16 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 16 Oct 2020 23:50:16 GMT Subject: RFR: 8243962: Various JVM TI tests time out using JFR on Windows In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 23:28:34 GMT, Serguei Spitsyn wrote: > I'd suggest to simplify the requires statement from: > > * * @requires !vm.flightRecorder | !(vm.debug & os.family == "windows") > > > to: > > * * @requires !vm.flightRecorder | !vm.debug | os.family != "windows" How about: * @requires !(vm.flightRecorder & vm.debug & os.family == "windows") This to me more clearly explains that these 3 flags can't be used together. ------------- PR: https://git.openjdk.java.net/jdk/pull/712 From sspitsyn at openjdk.java.net Sat Oct 17 01:21:06 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 17 Oct 2020 01:21:06 GMT Subject: RFR: 8243962: Various JVM TI tests time out using JFR on Windows In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 23:47:13 GMT, Chris Plummer wrote: > How about: > * @requires !(vm.flightRecorder & vm.debug & os.family == "windows") I'm okay with this suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/712 From pliden at openjdk.java.net Sat Oct 17 08:41:11 2020 From: pliden at openjdk.java.net (Per Liden) Date: Sat, 17 Oct 2020 08:41:11 GMT Subject: RFR: 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing In-Reply-To: References: Message-ID: <72iYV_Auz_bupXPDK8ZH-hiClojQTqI97Pz9inxdQaY=.4052ddca-8187-4143-beee-ac2923409374@github.com> On Fri, 16 Oct 2020 14:29:46 GMT, Stefan Karlsson wrote: > The cm03t001 test creates a local JNI handle in the prepare function. It later uses that handle from a callback > function, from another thread. When the callback runs, ZGC applies a load barrier to that handle and self-heals it in > the other threads stack. Later when that thread verifies its stack, during the start of its stack processing, it finds > that the oop is unexpectedly not "bad". It's invalid to send a local JNI handle over to another thread: > https://docs.oracle.com/en/java/javase/15/docs/specs/jni/design.html#global-and-local-references > So, my proposed fix is to convert the local handle to a global handle. > > I've tested this with the reproducer in the bug report. Marked as reviewed by pliden (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/701 From mgronlun at openjdk.java.net Sat Oct 17 13:03:23 2020 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Sat, 17 Oct 2020 13:03:23 GMT Subject: RFR: 8243962: Various JVM TI tests time out using JFR on Windows [v2] In-Reply-To: References: Message-ID: <5seyUUYDlyNS7rvP1fhLNSrAS3BuJKVHJcDsJ7ZNTDs=.4e46af79-70f8-4d92-935f-04017dedefb1@github.com> > Greetings, > > JDK-8243962 has been a large effort to chase down intermittent timeouts for certain JVMTI tests when run on Windows > debug builds in combination with JFR. The background is long, included in JDK-8243962. > In short, the combination of some JVMTI thread suspension tests when run together with JFR on saturated Windows 2016 > debug builds can intermittently time out. > There have been two major changes made to JFR derived from JDK-8243962 (linked therein) in an attempt to reduce the > poor scalability observed. > Unfortunately, the efforts have not fully resolved the situation entirely as there have still been intermittent > sightings for the following tests: > vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/TestDescription.java > vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/TestDescription.java > vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/TestDescription.java > vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/TestDescription.java > > This change will add a requires expression to these tests to exclude the combination of running them with JFR on > Windows debug builds. > Thanks > Markus Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - deMorgan - Merge branch 'master' into 8243962 - 8243962: Various JVM TI tests time out using JFR on Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/712/files - new: https://git.openjdk.java.net/jdk/pull/712/files/4f899253..cf381fcc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=712&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=712&range=00-01 Stats: 162 lines in 21 files changed: 95 ins; 32 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/712.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/712/head:pull/712 PR: https://git.openjdk.java.net/jdk/pull/712 From rrich at openjdk.java.net Sun Oct 18 06:20:25 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Sun, 18 Oct 2020 06:20:25 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v12] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: handle_special_runtime_exit_condition(): wait (blocked) for obj. deoptimization _before_ async ex. check. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/119/files - new: https://git.openjdk.java.net/jdk/pull/119/files/f02f07b6..272fb025 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=10-11 Stats: 10 lines in 1 file changed: 5 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From sspitsyn at openjdk.java.net Sun Oct 18 07:13:11 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sun, 18 Oct 2020 07:13:11 GMT Subject: RFR: 8243962: Various JVM TI tests time out using JFR on Windows [v2] In-Reply-To: <5seyUUYDlyNS7rvP1fhLNSrAS3BuJKVHJcDsJ7ZNTDs=.4e46af79-70f8-4d92-935f-04017dedefb1@github.com> References: <5seyUUYDlyNS7rvP1fhLNSrAS3BuJKVHJcDsJ7ZNTDs=.4e46af79-70f8-4d92-935f-04017dedefb1@github.com> Message-ID: <3doG-OYzY6agsPM6azERL3xSnnvjklIRlO0P89alxdI=.9d2b4b39-31bb-428c-b9d7-7169b1bcf39d@github.com> On Sat, 17 Oct 2020 13:03:23 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> JDK-8243962 has been a large effort to chase down intermittent timeouts for certain JVMTI tests when run on Windows >> debug builds in combination with JFR. The background is long, included in JDK-8243962. >> In short, the combination of some JVMTI thread suspension tests when run together with JFR on saturated Windows 2016 >> debug builds can intermittently time out. >> There have been two major changes made to JFR derived from JDK-8243962 (linked therein) in an attempt to reduce the >> poor scalability observed. >> Unfortunately, the efforts have not fully resolved the situation entirely as there have still been intermittent >> sightings for the following tests: >> vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/TestDescription.java >> vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/TestDescription.java >> vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/TestDescription.java >> vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/TestDescription.java >> >> This change will add a requires expression to these tests to exclude the combination of running them with JFR on >> Windows debug builds. >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - deMorgan > - Merge branch 'master' into 8243962 > - 8243962: Various JVM TI tests time out using JFR on Windows Looks good! ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/712 From vromero at openjdk.java.net Sun Oct 18 16:12:22 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 18 Oct 2020 16:12:22 GMT Subject: RFR: 8246774: implement Record Classes as a standard feature in Java [v12] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implement Record Classes as a standard feature in Java Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' into JDK-8246774 - Merge branch 'master' into JDK-8246774 - removing unused jcod file - remove unnecessary jtreg tags from tests, remove othervm etc when applicable - adding missing changes to some tests - modifiying @since from 14 to 16 - Remove preview args from ObjectMethodsTest - Remove preview args from record serialization tests - removing the javax.lang.model related code to be moved to a separate bug - 8246774: Record Classes (final) implementation Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Jonathan Gibbons Co-authored-by: Brian Goetz Co-authored-by: Maurizio Cimadamore Co-authored-by: Joe Darcy Co-authored-by: Chris Hegarty Co-authored-by: Jan Lahoda ------------- Changes: https://git.openjdk.java.net/jdk/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=11 Stats: 856 lines in 109 files changed: 72 ins; 562 del; 222 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Sun Oct 18 16:40:31 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 18 Oct 2020 16:40:31 GMT Subject: RFR: 8246774: implement Record Classes as a standard feature in Java [v13] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implement Record Classes as a standard feature in Java Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing reference to unused jcod file from test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/5bfbde59..3e472bc3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=11-12 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Sun Oct 18 18:58:16 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 18 Oct 2020 18:58:16 GMT Subject: Integrated: 8246774: implement Record Classes as a standard feature in Java In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Mon, 21 Sep 2020 21:30:51 GMT, Vicente Romero wrote: > 8246774: implement Record Classes as a standard feature in Java This pull request has now been integrated. Changeset: c17d5851 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/c17d5851 Stats: 856 lines in 109 files changed: 72 ins; 562 del; 222 mod 8246774: implement Record Classes as a standard feature in Java Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Chris Hegarty Reviewed-by: coleenp, jlahoda, sspitsyn, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From cjplummer at openjdk.java.net Sun Oct 18 20:15:12 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Sun, 18 Oct 2020 20:15:12 GMT Subject: RFR: 8243962: Various JVM TI tests time out using JFR on Windows [v2] In-Reply-To: <5seyUUYDlyNS7rvP1fhLNSrAS3BuJKVHJcDsJ7ZNTDs=.4e46af79-70f8-4d92-935f-04017dedefb1@github.com> References: <5seyUUYDlyNS7rvP1fhLNSrAS3BuJKVHJcDsJ7ZNTDs=.4e46af79-70f8-4d92-935f-04017dedefb1@github.com> Message-ID: On Sat, 17 Oct 2020 13:03:23 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> JDK-8243962 has been a large effort to chase down intermittent timeouts for certain JVMTI tests when run on Windows >> debug builds in combination with JFR. The background is long, included in JDK-8243962. >> In short, the combination of some JVMTI thread suspension tests when run together with JFR on saturated Windows 2016 >> debug builds can intermittently time out. >> There have been two major changes made to JFR derived from JDK-8243962 (linked therein) in an attempt to reduce the >> poor scalability observed. >> Unfortunately, the efforts have not fully resolved the situation entirely as there have still been intermittent >> sightings for the following tests: >> vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/TestDescription.java >> vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/TestDescription.java >> vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/TestDescription.java >> vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/TestDescription.java >> >> This change will add a requires expression to these tests to exclude the combination of running them with JFR on >> Windows debug builds. >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - deMorgan > - Merge branch 'master' into 8243962 > - 8243962: Various JVM TI tests time out using JFR on Windows Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/712 From ysuenaga at openjdk.java.net Mon Oct 19 01:35:13 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 19 Oct 2020 01:35:13 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> Message-ID: <-Xrp6c94000-jE1p6NvzjsxFUW5ILrH_F1eT1i7esw8=.9d609f81-1b61-4ebf-9afd-73b834c1b18c@github.com> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: >> I was initially wrong by supporting this, and now I share David's concerns about unclear semantics of this. The >> questions are: >> - Q1: Is it necessary to call the Agent_OnUnload()? >> - Q2: Would it be a JVMTI spec violation to call the Agent_OnAttach() multiple times? (It seems to be the case to me.) >> - Q3: What has to be done for statically linked agent? >> - Q4: Should the agent be correctly loadable in the first place? What were the reasons its loading to fail? >> >> Yes, at least, a CSR is needed for this. > >> * Q1: Is it necessary to call the Agent_OnUnload()? > > [JVMTI spec of Agent_OnUnload()](https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#onunload) says this > function will be called when the agent library will be unloaded by platform specific mechanism. OTOH it also says > `Agent_OnUnload()` will be called both at VM termination and **by other reasons**. The spec don't say for the case if > `Agent_OnAttach()` would be failed. IMHO `Agent_OnUnload()` should be called because this PR would unload library if > `Agent_OnAttach()` failed. >> * Q2: Would it be a JVMTI spec violation to call the Agent_OnAttach() multiple times? (It seems to be the case to me.) > > `Agent_OnAttach()` should be called only once per attach request, but VM should accept multiple attach request for same > agent library. > For example, we can add multiple `-agentlib` and `-agentpath` request as below. JVMTI agent might change behavior due > to arguments or configuration file. > -agentlib:test=profile=A -agentlib:test=profile=B -agentpath:/path/to/libtest=profile=C > > Agent developers should have responsibility for the behavior when more than one agent is loaded at a time. > >> * Q3: What has to be done for statically linked agent? > > JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() > in this PR. >> * Q4: Should the agent be correctly loadable in the first place? What were the reasons its loading to fail? > > Agent (`Agent_OnAttach()`) might fail due to error in agent logic. For example, some agents load configuration file at > initialization. If the user gives wrong value, it will fail. >> Yes, at least, a CSR is needed for this. > > I will file CSR for this PR after this discussion. If we can change the spec that agent library would not be unloaded when `Agent_OnAttach()` failed, we can change like [webrev.00](https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/). It is simple, and similar behavior with `Agent_OnLoad()`. It might be prefer for JVMTI agent developers. ------------- PR: https://git.openjdk.java.net/jdk/pull/19 From rrich at openjdk.java.net Mon Oct 19 05:18:31 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 19 Oct 2020 05:18:31 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v13] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Removed cross_modify_fence from JT::wait_for_object_deoptimization(). See JDK-8254264. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/119/files - new: https://git.openjdk.java.net/jdk/pull/119/files/272fb025..2ca09188 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=11-12 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From shade at openjdk.java.net Mon Oct 19 06:23:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 19 Oct 2020 06:23:16 GMT Subject: RFR: 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage [v2] In-Reply-To: References: Message-ID: > `LowMemoryDetector::check_memory_usage` seems declared but not implemented. Current history does not show any > definitions since the initial load. Can be removed. > Testing: > - [x] Linux x86_64 build > - [x] Test search for `check_memory_usage` in `src/hotspot` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage ------------- Changes: https://git.openjdk.java.net/jdk/pull/659/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=659&range=01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/659.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/659/head:pull/659 PR: https://git.openjdk.java.net/jdk/pull/659 From shade at openjdk.java.net Mon Oct 19 06:38:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 19 Oct 2020 06:38:16 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v2] In-Reply-To: References: Message-ID: <4PVuHaDhnUx61L4tg9slmrd6KDHuwjABffj2bVce1RM=.c574f639-2c21-44cb-bc78-3d69d54e68de@github.com> > This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like > this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to > `Instrumentation`, and let the tools use that fast path today. With this patch, JOL is able to be close to > `deepSizeOf` implementation from SizeOf JEP. > Example performance improvements for sizing up a custom linked list: > > Benchmark (size) Mode Cnt Score Error Units > > # Default > LinkedChainBench.linkedChain 1 avgt 5 705.835 ? 8.051 ns/op > LinkedChainBench.linkedChain 10 avgt 5 3148.874 ? 37.856 ns/op > LinkedChainBench.linkedChain 100 avgt 5 28693.256 ? 142.254 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 290161.590 ? 4594.631 ns/op > > # Instrumentation attached, no intrinsics > LinkedChainBench.linkedChain 1 avgt 5 159.659 ? 19.238 ns/op > LinkedChainBench.linkedChain 10 avgt 5 717.659 ? 22.540 ns/op > LinkedChainBench.linkedChain 100 avgt 5 7739.394 ? 111.683 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 80724.238 ? 2887.794 ns/op > > # Instrumentation attached, new intrinsics > LinkedChainBench.linkedChain 1 avgt 5 95.254 ? 0.808 ns/op > LinkedChainBench.linkedChain 10 avgt 5 261.564 ? 8.524 ns/op > LinkedChainBench.linkedChain 100 avgt 5 3367.192 ? 21.128 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 34148.851 ? 373.080 ns/op Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8253525: Implement getInstanceSize/sizeOf intrinsics ------------- Changes: https://git.openjdk.java.net/jdk/pull/650/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=01 Stats: 612 lines in 10 files changed: 563 ins; 0 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/650.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/650/head:pull/650 PR: https://git.openjdk.java.net/jdk/pull/650 From shade at openjdk.java.net Mon Oct 19 06:57:24 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 19 Oct 2020 06:57:24 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3] In-Reply-To: References: Message-ID: > This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like > this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to > `Instrumentation`, and let the tools use that fast path today. With this patch, JOL is able to be close to > `deepSizeOf` implementation from SizeOf JEP. > Example performance improvements for sizing up a custom linked list: > > Benchmark (size) Mode Cnt Score Error Units > > # Default > LinkedChainBench.linkedChain 1 avgt 5 705.835 ? 8.051 ns/op > LinkedChainBench.linkedChain 10 avgt 5 3148.874 ? 37.856 ns/op > LinkedChainBench.linkedChain 100 avgt 5 28693.256 ? 142.254 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 290161.590 ? 4594.631 ns/op > > # Instrumentation attached, no intrinsics > LinkedChainBench.linkedChain 1 avgt 5 159.659 ? 19.238 ns/op > LinkedChainBench.linkedChain 10 avgt 5 717.659 ? 22.540 ns/op > LinkedChainBench.linkedChain 100 avgt 5 7739.394 ? 111.683 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 80724.238 ? 2887.794 ns/op > > # Instrumentation attached, new intrinsics > LinkedChainBench.linkedChain 1 avgt 5 95.254 ? 0.808 ns/op > LinkedChainBench.linkedChain 10 avgt 5 261.564 ? 8.524 ns/op > LinkedChainBench.linkedChain 100 avgt 5 3367.192 ? 21.128 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 34148.851 ? 373.080 ns/op Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8253525: Implement getInstanceSize/sizeOf intrinsics ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/650/files - new: https://git.openjdk.java.net/jdk/pull/650/files/d744a913..6160f6a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/650.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/650/head:pull/650 PR: https://git.openjdk.java.net/jdk/pull/650 From stefank at openjdk.java.net Mon Oct 19 07:12:10 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 19 Oct 2020 07:12:10 GMT Subject: RFR: 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing In-Reply-To: <72iYV_Auz_bupXPDK8ZH-hiClojQTqI97Pz9inxdQaY=.4052ddca-8187-4143-beee-ac2923409374@github.com> References: <72iYV_Auz_bupXPDK8ZH-hiClojQTqI97Pz9inxdQaY=.4052ddca-8187-4143-beee-ac2923409374@github.com> Message-ID: On Sat, 17 Oct 2020 08:38:10 GMT, Per Liden wrote: >> The cm03t001 test creates a local JNI handle in the prepare function. It later uses that handle from a callback >> function, from another thread. When the callback runs, ZGC applies a load barrier to that handle and self-heals it in >> the other threads stack. Later when that thread verifies its stack, during the start of its stack processing, it finds >> that the oop is unexpectedly not "bad". It's invalid to send a local JNI handle over to another thread: >> https://docs.oracle.com/en/java/javase/15/docs/specs/jni/design.html#global-and-local-references >> So, my proposed fix is to convert the local handle to a global handle. >> >> I've tested this with the reproducer in the bug report. > > Marked as reviewed by pliden (Reviewer). Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/701 From stefank at openjdk.java.net Mon Oct 19 07:25:18 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 19 Oct 2020 07:25:18 GMT Subject: Integrated: 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 14:29:46 GMT, Stefan Karlsson wrote: > The cm03t001 test creates a local JNI handle in the prepare function. It later uses that handle from a callback > function, from another thread. When the callback runs, ZGC applies a load barrier to that handle and self-heals it in > the other threads stack. Later when that thread verifies its stack, during the start of its stack processing, it finds > that the oop is unexpectedly not "bad". It's invalid to send a local JNI handle over to another thread: > https://docs.oracle.com/en/java/javase/15/docs/specs/jni/design.html#global-and-local-references > So, my proposed fix is to convert the local handle to a global handle. > > I've tested this with the reproducer in the bug report. This pull request has now been integrated. Changeset: 672f5669 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/672f5669 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing Reviewed-by: tschatzl, cjplummer, sspitsyn, pliden ------------- PR: https://git.openjdk.java.net/jdk/pull/701 From mgronlun at openjdk.java.net Mon Oct 19 09:19:10 2020 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 19 Oct 2020 09:19:10 GMT Subject: RFR: 8243962: Various JVM TI tests time out using JFR on Windows [v2] In-Reply-To: References: <5seyUUYDlyNS7rvP1fhLNSrAS3BuJKVHJcDsJ7ZNTDs=.4e46af79-70f8-4d92-935f-04017dedefb1@github.com> Message-ID: <_WG30QoHx2z6mtRc56qecgxW1itLflu1tJ6dy0Q3kl4=.6b3e2b15-a6b6-4413-8dfc-806bf466c042@github.com> On Sun, 18 Oct 2020 20:12:31 GMT, Chris Plummer wrote: >> Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since >> the last revision: >> - deMorgan >> - Merge branch 'master' into 8243962 >> - 8243962: Various JVM TI tests time out using JFR on Windows > > Looks good. Thanks @plummercj and @sspitsyn for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/712 From mgronlun at openjdk.java.net Mon Oct 19 09:23:09 2020 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 19 Oct 2020 09:23:09 GMT Subject: Integrated: 8243962: Various JVM TI tests time out using JFR on Windows In-Reply-To: References: Message-ID: <2DkRcDVLlpuCfK1JIvXLvGRCc5hTt0cZoMlMcZbPKzo=.17c895c9-a75c-486c-8df5-cc33928c4590@github.com> On Fri, 16 Oct 2020 22:30:14 GMT, Markus Gr?nlund wrote: > Greetings, > > JDK-8243962 has been a large effort to chase down intermittent timeouts for certain JVMTI tests when run on Windows > debug builds in combination with JFR. The background is long, included in JDK-8243962. > In short, the combination of some JVMTI thread suspension tests when run together with JFR on saturated Windows 2016 > debug builds can intermittently time out. > There have been two major changes made to JFR derived from JDK-8243962 (linked therein) in an attempt to reduce the > poor scalability observed. > Unfortunately, the efforts have not fully resolved the situation entirely as there have still been intermittent > sightings for the following tests: > vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/TestDescription.java > vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/TestDescription.java > vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/TestDescription.java > vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/TestDescription.java > > This change will add a requires expression to these tests to exclude the combination of running them with JFR on > Windows debug builds. > Thanks > Markus This pull request has now been integrated. Changeset: e10b5385 Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/e10b5385 Stats: 8 lines in 4 files changed: 8 ins; 0 del; 0 mod 8243962: Various JVM TI tests time out using JFR on Windows Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/712 From rehn at openjdk.java.net Mon Oct 19 10:41:15 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 19 Oct 2020 10:41:15 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended Message-ID: The main point of this change-set is to make it easier to implement S/R on top of handshakes. Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). But we also remove some complicated S/R methods. We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. ------------- Commit messages: - Utilize handshakes instead of is_thread_fully_suspended Changes: https://git.openjdk.java.net/jdk/pull/729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=729&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223312 Stats: 480 lines in 6 files changed: 158 ins; 266 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/729/head:pull/729 PR: https://git.openjdk.java.net/jdk/pull/729 From lzang at openjdk.java.net Mon Oct 19 11:57:27 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 19 Oct 2020 11:57:27 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v2] In-Reply-To: References: Message-ID: > - Parallel heap iteration support for PSS > - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8252103: Parallel heap inspection for ParallelScavengeHeap - Parallel heap iteration support for PSS - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/25/files - new: https://git.openjdk.java.net/jdk/pull/25/files/23e09ec4..3672513a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=25&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=25&range=00-01 Stats: 212 lines in 6 files changed: 85 ins; 80 del; 47 mod Patch: https://git.openjdk.java.net/jdk/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/25/head:pull/25 PR: https://git.openjdk.java.net/jdk/pull/25 From lzang at openjdk.java.net Mon Oct 19 12:36:21 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 19 Oct 2020 12:36:21 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap In-Reply-To: References: <1xp0kyi05gXKng-W44aZ---XzUKoTi0KyQnagMml74c=.10a80aa0-ba28-4f96-9f2a-867aa68496d0@github.com> <3Ht7FuvxDYvrvOF0u1hFihHmSnQsSTldXcNORnGOE84=.2770966d-051f-4202-a4d6-0bc071faa1a7@github.com> Message-ID: <7qWPzrQr4V-atf1GvPbe2gkaymj3sDd1A6qLhotEJh0=.806de815-3c9c-487b-beb1-756d37068207@github.com> On Fri, 9 Oct 2020 14:23:31 GMT, Lin Zang wrote: >> Hi @kstefanj, Thanks a lot for your comments. >> I think there can be a reclaimer that treat eden space, from space, to space and "blocks" in old space as parallel >> iteration candidates, then every workers try to claim their ownership of the candidate that it is going to scan. So >> there is no need to check worker numbers and Id for processing different spaces. what do you think? >> BTW, Paul (hohensee at amazon.com) also helped review this patch and send the comment in mail list, I will paste his >> comments here and then try to polish a patch with all of your comments considered. > > Here is the review comments from Paul, copied from hotspot-gc-dev digest: >> Message: 3 >> Date: Mon, 28 Sep 2020 22:39:38 +0000 >> From: "Hohensee, Paul" >> To: Lin Zang , >> "hotspot-gc-dev at openjdk.java.net" , >> "serviceability-dev at openjdk.java.net" >> >> Subject: RE: RFR: 8252103: Parallel heap inspection for >> ParallelScavengeHeap >> Message-ID: <25A4DC80-74A8-4C99-AEF4-7E989317B18A at amazon.com> >> Content-Type: text/plain; charset="utf-8" >> >> I'm not a GC specialist, but your approach looks reasonable to me. >> >> parallelScavengeHeap.cpp: >> >> "less that 1 workers" -> "less that 1 worker" >> >> psOldGen.cpp: >> >> ">=2" -> ">= 2" >> >> "thread_num-2 worker" -> "(thread_num -2) workers" >> >> "cross blocks" -> "crosses blocks" >> >> "that the object start address locates in the related block" -> "that owns the block within which the object starts" >> >> blocks_iterate_parallel() relies on BLOCK_SIZE being an integral multiple of a start_array() block (i.e., >> ObjectStartArray::block_size). I'd add an assert to that effect. >> The comment on the definition of BLOCK_SIZE is "64 KB", but you're doing pointer arithmetic in terms of HeapWords, >> which > means the actual byte value is either 256KB or 512KB for 32- and 64-bit respectively. You could use >> const int BLOCK_SIZE = (64 * 1024 / HeapWordSize); >> >> "// There is objects" -> "There are objects" >> >> "reture" -> "return" >> >> ", here only focus objects" -> ". Here only focus on objects" >> >> It's a matter of taste, but imo the loop in blocks_iterate_parallel() would be more clear as >> >> for (HeapWord* p = start; p < end; p += oop(p)->size()) { >> cl->do_object(oop(p)); >> } >> >> psOldGen.hpp: >> >> blocks_iterate_parallel() is pure implementation and I don't see a reference outside psOldGen.cpp. So, it should be >> private, > not public. >> >> psYoungGen.cpp: >> >> "<=1" -> "<= 1" >> >> Thanks, >> Paul > > Thanks for Paul's help and effort for reviewing, I will make a refined patch based on your comments. Dear @stefank, I have update this PR that use a claimer to help worker thread do parallel iteration. would you like to help review again? Thanks, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From lzang at openjdk.java.net Mon Oct 19 12:36:21 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 19 Oct 2020 12:36:21 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v3] In-Reply-To: References: Message-ID: <7eLCJi9HCnxoo_-eB3EKfvGZIxc-WMdl9sK-Hnim2Vk=.f6569509-748b-4000-86ad-c5f7f9a153d2@github.com> > - Parallel heap iteration support for PSS > - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8252103: Parallel heap inspection for ParallelScavengeHeap - Parallel heap iteration support for PSS - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/25/files - new: https://git.openjdk.java.net/jdk/pull/25/files/3672513a..05f3c64f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=25&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=25&range=01-02 Stats: 8 lines in 3 files changed: 1 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/25/head:pull/25 PR: https://git.openjdk.java.net/jdk/pull/25 From lzang at openjdk.java.net Mon Oct 19 13:09:34 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 19 Oct 2020 13:09:34 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v4] In-Reply-To: References: Message-ID: > - Parallel heap iteration support for PSS > - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8252103: Parallel heap inspection for ParallelScavengeHeap - Parallel heap iteration support for PSS - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/25/files - new: https://git.openjdk.java.net/jdk/pull/25/files/05f3c64f..2878fc01 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=25&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=25&range=02-03 Stats: 15 lines in 2 files changed: 0 ins; 15 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/25/head:pull/25 PR: https://git.openjdk.java.net/jdk/pull/25 From iignatyev at openjdk.java.net Mon Oct 19 17:03:10 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 19 Oct 2020 17:03:10 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 22:47:43 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this patch which reformats/cleans up the code of vmTestbase/nsk/jdb tests? > > the part of this patch is a spinoff from #350. > > testing: > * [x] `vmTestbase/nsk/jdb` tests on `linux-x64-debug` ping? ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From sspitsyn at openjdk.java.net Mon Oct 19 17:57:17 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 19 Oct 2020 17:57:17 GMT Subject: RFR: 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage [v2] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 06:23:16 GMT, Aleksey Shipilev wrote: >> `LowMemoryDetector::check_memory_usage` seems declared but not implemented. Current history does not show any >> definitions since the initial load. Can be removed. >> Testing: >> - [x] Linux x86_64 build >> - [x] Test search for `check_memory_usage` in `src/hotspot` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since > the last revision: > 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage This looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/659 From kvn at openjdk.java.net Mon Oct 19 18:17:18 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 19 Oct 2020 18:17:18 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 06:57:24 GMT, Aleksey Shipilev wrote: >> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like >> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to >> `Instrumentation`, and let the tools use that fast path today. With this patch, JOL is able to be close to >> `deepSizeOf` implementation from SizeOf JEP. >> Example performance improvements for sizing up a custom linked list: >> >> Benchmark (size) Mode Cnt Score Error Units >> >> # Default >> LinkedChainBench.linkedChain 1 avgt 5 705.835 ? 8.051 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 3148.874 ? 37.856 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 28693.256 ? 142.254 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 290161.590 ? 4594.631 ns/op >> >> # Instrumentation attached, no intrinsics >> LinkedChainBench.linkedChain 1 avgt 5 159.659 ? 19.238 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 717.659 ? 22.540 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 7739.394 ? 111.683 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 80724.238 ? 2887.794 ns/op >> >> # Instrumentation attached, new intrinsics >> LinkedChainBench.linkedChain 1 avgt 5 95.254 ? 0.808 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 261.564 ? 8.524 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 3367.192 ? 21.128 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 34148.851 ? 373.080 ns/op > > Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. Always run graalunit testing with new intrinsics. You need to adjust Graal test: src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/650 From cjplummer at openjdk.java.net Mon Oct 19 18:33:13 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 19 Oct 2020 18:33:13 GMT Subject: RFR: 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage [v2] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 06:23:16 GMT, Aleksey Shipilev wrote: >> `LowMemoryDetector::check_memory_usage` seems declared but not implemented. Current history does not show any >> definitions since the initial load. Can be removed. >> Testing: >> - [x] Linux x86_64 build >> - [x] Test search for `check_memory_usage` in `src/hotspot` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains one commit: > 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/659 From rrich at openjdk.java.net Mon Oct 19 18:48:29 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 19 Oct 2020 18:48:29 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v14] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge branch 'master' into JDK-8227745 - Removed cross_modify_fence from JT::wait_for_object_deoptimization(). See JDK-8254264. - handle_special_runtime_exit_condition(): wait (blocked) for obj. deoptimization _before_ async ex. check. - Removed unused parameter from EscapeBarrierSuspendHandshake. - Adaptations to JDK-8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() With JDK-8254263 the special_runtime_exit_condition() check was removed from ~ThreadInVMForHandshake() because now a thread never becomes unsafe when processing its own handshakes. EscapeBarrier uses handshakes to sync with the target thread for object deoptimization so we add a check for object deoptimization to ThreadSafepointState::handle_polling_page_exception(). In JavaThread::wait_for_object_deoptimization() we must check is_obj_deopt_suspend() again after handshake/safepoint processing because a handshake for obj. deopt suspend could have been processed. - Adaptions to lazy/concurrent thread stack processing for ZGC (JEP 376) - EATests.java improvements - Merge branch 'master' into JDK-8227745 - The constructor of StackFrameStream takes more parameters after JDK-8253180 - Merge branch 'master' into JDK-8227745 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/1da28de8...8d09747b ------------- Changes: https://git.openjdk.java.net/jdk/pull/119/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=13 Stats: 5860 lines in 53 files changed: 5642 ins; 116 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From cjplummer at openjdk.java.net Mon Oct 19 18:59:29 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 19 Oct 2020 18:59:29 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 23:25:25 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this patch which reformats/cleans up the code of vmTestbase/nsk/jdb tests? >> >> the part of this patch is a spinoff from #350. >> >> testing: >> * [x] `vmTestbase/nsk/jdb` tests on `linux-x64-debug` > > Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years I've gotten about halfway through. I'll wait for your responses before doing the rest since I don't want to keep tagging the same issues. test/hotspot/jtreg/vmTestbase/nsk/jdb/caught_exception/caught_exception002/caught_exception002.java line 87: > 85: static final String DEBUGGEE_CLASS = TEST_CLASS + "a"; > 86: static final String FIRST_BREAK = DEBUGGEE_CLASS + ".main"; > 87: static final String LAST_BREAK = DEBUGGEE_CLASS + ".lastBreak"; I'm not so sure I'd consider this change an improvement. Maybe remove some of the extra spaces but keep the alignment. test/hotspot/jtreg/vmTestbase/nsk/jdb/caught_exception/caught_exception002/caught_exception002a.java line 42: > 40: } > 41: > 42: public int runIt(String[] args, PrintStream out) { Is there a style guide that says this is the preferred way to declare an array type? I count 3700 occurrences of "String args[]" in ours tests. test/hotspot/jtreg/vmTestbase/nsk/jdb/fields/fields001/fields001.java line 108: > 106: "ii_aa", "oi_aa", > 107: "ii_aaa", "oi_aaa" > 108: }; Why are these indented 8 instead of 4? test/hotspot/jtreg/vmTestbase/nsk/jdb/hidden_class/hc001/hc001.java line 323: > 321: "xx.yyy/0x111/0x222", > 322: "xx./0x111.0x222", > 323: "xx.yyy.zzz/" Why are these indented 8 instead of 4? ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From rrich at openjdk.java.net Mon Oct 19 19:41:14 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 19 Oct 2020 19:41:14 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v10] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 20:50:45 GMT, Richard Reingruber wrote: >> Good. > >> >> >> Good. > > Thanks for the review, Vladimir (@vnkozlov)! > I'm still (stress) testing adaptations to lazy/concurrent thread stack processing for ZGC. > --Richard. Thanks once more @TheRealMDoerr, @GoeLin, @dholmes-ora, @sspitsyn, @vnkozlov, @robehn, @pchilano for feedback and reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From iignatyev at openjdk.java.net Mon Oct 19 20:52:15 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 19 Oct 2020 20:52:15 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 18:44:56 GMT, Chris Plummer wrote: >> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright years > > test/hotspot/jtreg/vmTestbase/nsk/jdb/caught_exception/caught_exception002/caught_exception002a.java line 42: > >> 40: } >> 41: >> 42: public int runIt(String[] args, PrintStream out) { > > Is there a style guide that says this is the preferred way to declare an array type? I count 3700 occurrences of > "String args[]" in ours tests. yes, there is, e.g. [Java Style Guidelines](http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-variable-declarations) by Andreas Lundblad: > Square brackets of arrays should be at the type (String[] args) and not on the variable (String args[]). although @aioobe's guidelines have been accepted (yet?) to the openjdk guide (see openjdk/guide#14), this particular item is agreed on and accepted almost unanimously in the industry. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From iignatyev at openjdk.java.net Mon Oct 19 21:00:21 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 19 Oct 2020 21:00:21 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 18:51:15 GMT, Chris Plummer wrote: >> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright years > > test/hotspot/jtreg/vmTestbase/nsk/jdb/fields/fields001/fields001.java line 108: > >> 106: "ii_aa", "oi_aa", >> 107: "ii_aaa", "oi_aaa" >> 108: }; > > Why are these indented 8 instead of 4? b/c you get indentation unit for each block, 1st block is `fields001` class definition, next block is the array initializations (start at L#86 and L#99 for `checkedFields1` and `checkedFields2` respecitively) > test/hotspot/jtreg/vmTestbase/nsk/jdb/hidden_class/hc001/hc001.java line 323: > >> 321: "xx.yyy/0x111/0x222", >> 322: "xx./0x111.0x222", >> 323: "xx.yyy.zzz/" > > Why are these indented 8 instead of 4? due to the same reasons in the case w/ `fields001`, these lines have 3 unit indentation, 1st for `hc001` class, 2nd for `testInvalidCommands` method, 3rd for `invClassNames` array initialization, so they have 3x4 = 12 spaces. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From cjplummer at openjdk.java.net Mon Oct 19 23:50:13 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 19 Oct 2020 23:50:13 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 20:49:14 GMT, Igor Ignatyev wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdb/caught_exception/caught_exception002/caught_exception002a.java line 42: >> >>> 40: } >>> 41: >>> 42: public int runIt(String[] args, PrintStream out) { >> >> Is there a style guide that says this is the preferred way to declare an array type? I count 3700 occurrences of >> "String args[]" in ours tests. > > yes, there is, e.g. [Java Style > Guidelines](http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-variable-declarations) by Andreas > Lundblad: >> Square brackets of arrays should be at the type (String[] args) and not on the variable (String args[]). > > although @aioobe's guidelines have been accepted (yet?) to the openjdk guide (see openjdk/guide#14), this particular > item is agreed on and accepted almost unanimously in the industry. ok ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From cjplummer at openjdk.java.net Tue Oct 20 00:00:08 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 20 Oct 2020 00:00:08 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 20:55:01 GMT, Igor Ignatyev wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdb/fields/fields001/fields001.java line 108: >> >>> 106: "ii_aa", "oi_aa", >>> 107: "ii_aaa", "oi_aaa" >>> 108: }; >> >> Why are these indented 8 instead of 4? > > b/c you get indentation unit for each block, 1st block is `fields001` class definition, next block is the array > initializations (start at L#86 and L#99 for `checkedFields1` and `checkedFields2` respecitively) I don't follow. You seem to have added an extra 4 (after having already indented 4 extra spaces) simply because it is an array initialization. Why is the indentation any different than it would be for something like a "for" loop block. The body of the block is indented 4 spaces more than the "for" statement. For the static initialization the body of that "static" block should be indented 4 more than the "static" statement. I don't see anything in the style guide that would indicate otherwise. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From iignatyev at openjdk.java.net Tue Oct 20 00:07:09 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 20 Oct 2020 00:07:09 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 18:37:58 GMT, Chris Plummer wrote: >> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright years > > test/hotspot/jtreg/vmTestbase/nsk/jdb/caught_exception/caught_exception002/caught_exception002.java line 87: > >> 85: static final String DEBUGGEE_CLASS = TEST_CLASS + "a"; >> 86: static final String FIRST_BREAK = DEBUGGEE_CLASS + ".main"; >> 87: static final String LAST_BREAK = DEBUGGEE_CLASS + ".lastBreak"; > > I'm not so sure I'd consider this change an improvement. Maybe remove some of the extra spaces but keep the alignment. although horizontal alignment (of variable names, initialization, expressions, etc) seems to somewhat improve readability, it almost always associated with a higher maintenance cost, and the current consensus is not to do that. from 'Horizontal Whitespace' section of the same [guidelines](http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-whitespace): > In variable declarations it is not recommended to align types and variables. *Motivation* The improvement in readability when aligning variable names is negligible compared to the efforts needed to keep them aligned as the code evolves. Realigning all variables when one of the types change also causes unnecessarily complicated patches to review. other java code guidelines either discourage horizontal alignment or consider it optional and provide the same motivation as above to why it's better not to have it. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From iignatyev at openjdk.java.net Tue Oct 20 00:24:08 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 20 Oct 2020 00:24:08 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 23:56:00 GMT, Chris Plummer wrote: >> b/c you get indentation unit for each block, 1st block is `fields001` class definition, next block is the array >> initializations (start at L#86 and L#99 for `checkedFields1` and `checkedFields2` respecitively) > > I don't follow. You seem to have added an extra 4 (after having already indented 4 extra spaces) simply because it is > an array initialization. Why is the indentation any different than it would be for something like a "for" loop block. > The body of the block is indented 4 spaces more than the "for" statement. For the static initialization the body of > that "static" block should be indented 4 more than the "static" statement. I don't see anything in the style guide that > would indicate otherwise. oh, sorry, it appears I was trying to explain the new code while looking at the old one... full disclaimer, which I thought was obvious, the vast majority of the changes here aren't done by me, they are done by auto-formatter, or more precisely by IntelliJ IDEA's formatter. IDEA doesn't consider array initialization as a new block, and what's actually at play here is an indent for statement continuation (which is 2x of regular indent). ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From cjplummer at openjdk.java.net Tue Oct 20 01:16:12 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 20 Oct 2020 01:16:12 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 00:04:16 GMT, Igor Ignatyev wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdb/caught_exception/caught_exception002/caught_exception002.java line 87: >> >>> 85: static final String DEBUGGEE_CLASS = TEST_CLASS + "a"; >>> 86: static final String FIRST_BREAK = DEBUGGEE_CLASS + ".main"; >>> 87: static final String LAST_BREAK = DEBUGGEE_CLASS + ".lastBreak"; >> >> I'm not so sure I'd consider this change an improvement. Maybe remove some of the extra spaces but keep the alignment. > > although horizontal alignment (of variable names, initialization, expressions, etc) seems to somewhat improve > readability, it almost always associated with a higher maintenance cost, and the current consensus is not to do that. > from 'Horizontal Whitespace' section of the same > [guidelines](http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-whitespace): >> In variable declarations it is not recommended to align types and variables. > *Motivation* > The improvement in readability when aligning variable names is negligible compared to the efforts needed to keep them > aligned as the code evolves. Realigning all variables when one of the types change also causes unnecessarily > complicated patches to review. other java code guidelines either discourage horizontal alignment or consider it > optional and provide the same motivation as above to why it's better not to have it. While in general I agree that gratuitous aligning of variables is not desirable, this is a special case where it adds value (enough that I think it's worth doing). The value here is due to the fact that the variables are building on each other. When they are aligned it's easier to scan for the variable (and its value) that another variable builds on. You can keep your change in place if you feel that consistency and maintainabilty is more important here than readability. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From dholmes at openjdk.java.net Tue Oct 20 02:31:11 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 20 Oct 2020 02:31:11 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended In-Reply-To: References: Message-ID: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> On Mon, 19 Oct 2020 09:59:34 GMT, Robbin Ehn wrote: > The main point of this change-set is to make it easier to implement S/R on top of handshakes. > Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). > But we also remove some complicated S/R methods. > > We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. > > TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. > But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. > > Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. Hi Robbin, IIUC the "waiting" part of `wait_for_ext_suspend_completion` is now implicitly handled in the handshake - correct? Overall this seems like a great simplification. A few minor comments below. Thanks, David src/hotspot/share/runtime/thread.cpp line 579: > 577: // That trace is very chatty. > 578: return; > 579: #else Without the !is_wait check none of the code below line 583 is reachable now. I would remove this now. src/hotspot/share/prims/jvmtiEnv.cpp line 1648: > 1646: op.doit(java_thread, true); > 1647: } else { > 1648: Handshake::execute(&op, java_thread); This pattern is repeated a lot - we should be able to incorporate it into the op itself by passing in `java_thread`. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1525: > 1523: Thread* current_thread = Thread::current(); > 1524: HandleMark hm(current_thread); > 1525: JavaThread* java_thread = target->as_Java_thread(); Contrast with the same three lines at L1390 - we should use the same boilerplate in each `doit`. And ideally refactor into some shared code somewhere (future RFE). ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/729 From shade at openjdk.java.net Tue Oct 20 05:34:14 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 20 Oct 2020 05:34:14 GMT Subject: Integrated: 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 14:57:20 GMT, Aleksey Shipilev wrote: > `LowMemoryDetector::check_memory_usage` seems declared but not implemented. Current history does not show any > definitions since the initial load. Can be removed. > Testing: > - [x] Linux x86_64 build > - [x] Test search for `check_memory_usage` in `src/hotspot` This pull request has now been integrated. Changeset: 0a75b37f Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/0a75b37f Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/659 From rehn at openjdk.java.net Tue Oct 20 06:18:13 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Oct 2020 06:18:13 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended In-Reply-To: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> References: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> Message-ID: On Tue, 20 Oct 2020 02:14:56 GMT, David Holmes wrote: >> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >> But we also remove some complicated S/R methods. >> >> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >> >> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >> >> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. > > src/hotspot/share/runtime/thread.cpp line 579: > >> 577: // That trace is very chatty. >> 578: return; >> 579: #else > > Without the !is_wait check none of the code below line 583 is reachable now. I would remove this now. Since only the destructor contains any actual functionality, which is now unreachable, should I remove the entire TraceSuspendDebugBits? ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From david.holmes at oracle.com Tue Oct 20 06:36:48 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Oct 2020 16:36:48 +1000 Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended In-Reply-To: References: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> Message-ID: <19c09caa-fb95-4508-46a0-15be2b4ad1fc@oracle.com> On 20/10/2020 4:18 pm, Robbin Ehn wrote: > On Tue, 20 Oct 2020 02:14:56 GMT, David Holmes wrote: > >>> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >>> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >>> But we also remove some complicated S/R methods. >>> >>> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >>> >>> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >>> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >>> >>> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. >> >> src/hotspot/share/runtime/thread.cpp line 579: >> >>> 577: // That trace is very chatty. >>> 578: return; >>> 579: #else >> >> Without the !is_wait check none of the code below line 583 is reachable now. I would remove this now. > > Since only the destructor contains any actual functionality, which is now unreachable, should I remove the entire > TraceSuspendDebugBits? Go for it! :) Davids > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/729 > From rehn at openjdk.java.net Tue Oct 20 07:15:25 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Oct 2020 07:15:25 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended In-Reply-To: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> References: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> Message-ID: On Tue, 20 Oct 2020 02:28:35 GMT, David Holmes wrote: >> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >> But we also remove some complicated S/R methods. >> >> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >> >> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >> >> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. > > Hi Robbin, > > IIUC the "waiting" part of `wait_for_ext_suspend_completion` is now implicitly handled in the handshake - correct? > > Overall this seems like a great simplification. > > A few minor comments below. > > Thanks, > David Hi David, thanks for having a look. > Hi Robbin, > > IIUC the "waiting" part of `wait_for_ext_suspend_completion` is now implicitly handled in the handshake - correct? A suspended Java thread may never transition back to java, never execute any more bytecodes. The old 'fully' suspended gives more guarantees which we need to do some operations. When we are in a handshake, the handshake gives us those guarantees, so it is enough that thread is considered suspended. So the answer is we wait until we are allowed to execute those operations (thread handshake safe), which is not identical with fully suspended. But fully suspended is an implementation detail, the agent only knows about suspended. > > Overall this seems like a great simplification. > > A few minor comments below. > > Thanks, > David ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Tue Oct 20 07:20:29 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Oct 2020 07:20:29 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended In-Reply-To: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> References: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> Message-ID: On Tue, 20 Oct 2020 02:22:15 GMT, David Holmes wrote: >> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >> But we also remove some complicated S/R methods. >> >> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >> >> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >> >> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. > > src/hotspot/share/prims/jvmtiEnv.cpp line 1648: > >> 1646: op.doit(java_thread, true); >> 1647: } else { >> 1648: Handshake::execute(&op, java_thread); > > This pattern is repeated a lot - we should be able to incorporate it into the op itself by passing in `java_thread`. My suggestion here is that we fix this in Handshake::execute() in separate RFE. > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1525: > >> 1523: Thread* current_thread = Thread::current(); >> 1524: HandleMark hm(current_thread); >> 1525: JavaThread* java_thread = target->as_Java_thread(); > > Contrast with the same three lines at L1390 - we should use the same boilerplate in each `doit`. And ideally refactor > into some shared code somewhere (future RFE). Yes, that would be good. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From david.holmes at oracle.com Tue Oct 20 07:26:27 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Oct 2020 17:26:27 +1000 Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended In-Reply-To: References: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> Message-ID: <4dd48ddc-d4cf-a86b-4a36-f6c707db422a@oracle.com> On 20/10/2020 5:20 pm, Robbin Ehn wrote: > On Tue, 20 Oct 2020 02:22:15 GMT, David Holmes wrote: > >>> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >>> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >>> But we also remove some complicated S/R methods. >>> >>> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >>> >>> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >>> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >>> >>> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. >> >> src/hotspot/share/prims/jvmtiEnv.cpp line 1648: >> >>> 1646: op.doit(java_thread, true); >>> 1647: } else { >>> 1648: Handshake::execute(&op, java_thread); >> >> This pattern is repeated a lot - we should be able to incorporate it into the op itself by passing in `java_thread`. > > My suggestion here is that we fix this in Handshake::execute() in separate RFE. Not clear to me this is so generic that it applies to Handshake::execute rather than being part of the operation. ?? David ----- >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1525: >> >>> 1523: Thread* current_thread = Thread::current(); >>> 1524: HandleMark hm(current_thread); >>> 1525: JavaThread* java_thread = target->as_Java_thread(); >> >> Contrast with the same three lines at L1390 - we should use the same boilerplate in each `doit`. And ideally refactor >> into some shared code somewhere (future RFE). > > Yes, that would be good. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/729 > From stefank at openjdk.java.net Tue Oct 20 07:43:26 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 20 Oct 2020 07:43:26 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap In-Reply-To: <7qWPzrQr4V-atf1GvPbe2gkaymj3sDd1A6qLhotEJh0=.806de815-3c9c-487b-beb1-756d37068207@github.com> References: <1xp0kyi05gXKng-W44aZ---XzUKoTi0KyQnagMml74c=.10a80aa0-ba28-4f96-9f2a-867aa68496d0@github.com> <3Ht7FuvxDYvrvOF0u1hFihHmSnQsSTldXcNORnGOE84=.2770966d-051f-4202-a4d6-0bc071faa1a7@github.com> <7qWPzrQr4V-atf1GvPbe2gkaymj3sDd1A6qLhotEJh0=.806de815-3c9c-487b-beb1-756d37068207@github.com> Message-ID: On Mon, 19 Oct 2020 12:21:27 GMT, Lin Zang wrote: > Dear @stefank, > I have update this PR that use a claimer to help worker thread do parallel iteration. would you like to help review > again? Thanks, > Lin Wrong Stefan, I think you mean @kstefanj ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From lzang at openjdk.java.net Tue Oct 20 07:47:25 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 20 Oct 2020 07:47:25 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap In-Reply-To: References: <1xp0kyi05gXKng-W44aZ---XzUKoTi0KyQnagMml74c=.10a80aa0-ba28-4f96-9f2a-867aa68496d0@github.com> <3Ht7FuvxDYvrvOF0u1hFihHmSnQsSTldXcNORnGOE84=.2770966d-051f-4202-a4d6-0bc071faa1a7@github.com> <7qWPzrQr4V-atf1GvPbe2gkaymj3sDd1A6qLhotEJh0=.806de815-3c9c-487b-beb1-756d37068207@github.com> Message-ID: On Tue, 20 Oct 2020 07:40:28 GMT, Stefan Karlsson wrote: >> Dear @stefank, >> I have update this PR that use a claimer to help worker thread do parallel iteration. would you like to help review >> again? Thanks, >> Lin > >> Dear @stefank, >> I have update this PR that use a claimer to help worker thread do parallel iteration. would you like to help review >> again? Thanks, >> Lin > > Wrong Stefan, I think you mean @kstefanj Hi @stefank, So sorry to bother you! Hi @kstefanj Would you like to help review this? Thanks! BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From sjohanss at openjdk.java.net Tue Oct 20 08:33:18 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 20 Oct 2020 08:33:18 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap In-Reply-To: References: <1xp0kyi05gXKng-W44aZ---XzUKoTi0KyQnagMml74c=.10a80aa0-ba28-4f96-9f2a-867aa68496d0@github.com> <3Ht7FuvxDYvrvOF0u1hFihHmSnQsSTldXcNORnGOE84=.2770966d-051f-4202-a4d6-0bc071faa1a7@github.com> <7qWPzrQr4V-atf1GvPbe2gkaymj3sDd1A6qLhotEJh0=.806de815-3c9c-487b-beb1-756d37068207@github.com> Message-ID: On Tue, 20 Oct 2020 07:44:54 GMT, Lin Zang wrote: >>> Dear @stefank, >>> I have update this PR that use a claimer to help worker thread do parallel iteration. would you like to help review >>> again? Thanks, >>> Lin >> >> Wrong Stefan, I think you mean @kstefanj > > Hi @stefank, > So sorry to bother you! > Hi @kstefanj > Would you like to help review this? Thanks! > > BRs, > Lin Hi Lin, I will take a look when I get time. In the middle of some other things right now. For future reference, you should avoid force pushing changes to open PRs. Instead of rebasing you can merge with master to make your branch up to date. This time it don't really matter since we didn't have any comments in the code, but otherwise those might be lost.? ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From lzang at openjdk.java.net Tue Oct 20 08:58:25 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 20 Oct 2020 08:58:25 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap In-Reply-To: References: <1xp0kyi05gXKng-W44aZ---XzUKoTi0KyQnagMml74c=.10a80aa0-ba28-4f96-9f2a-867aa68496d0@github.com> <3Ht7FuvxDYvrvOF0u1hFihHmSnQsSTldXcNORnGOE84=.2770966d-051f-4202-a4d6-0bc071faa1a7@github.com> <7qWPzrQr4V-atf1GvPbe2gkaymj3sDd1A6qLhotEJh0=.806de815-3c9c-487b-beb1-756d37068207@github.com> Message-ID: <4ts7JVLp-WMGJdvwYvW-5hXM-d8FF-l0XGCCvTqweYA=.e94fbec3-dea1-48dd-aa30-4100102b6c47@github.com> On Tue, 20 Oct 2020 08:30:24 GMT, Stefan Johansson wrote: > For future reference, you should avoid force pushing changes to open PRs. Instead of rebasing you can merge with master > to make your branch up to date. This time it don't really matter since we didn't have any comments in the code, but > otherwise those might be lost. Thanks for guidance, I will follow it in future. ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From ngasson at openjdk.java.net Tue Oct 20 09:34:29 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 20 Oct 2020 09:34:29 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file Message-ID: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> When using the Linux "perf" tool to do system profiling, symbol names of running Java methods cannot be decoded, resulting in unhelpful output such as: 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 Perf can read a simple text file format describing the mapping between address ranges and symbol names for a particular process [1]. It's possible to generate this already for Java processes using a JVMTI plugin such as perf-map-agent [2]. However this requires compiling third-party code and then loading the agent into your Java process. It would be more convenient if Hotspot could write this file directly using a diagnostic command. The information required is almost identical to that of the existing Compiler.codelist command. This patch adds a Compiler.perfmap diagnostic command on Linux only. To use, first run "jcmd Compiler.perfmap" and then "perf top" or "perf record" and the report should show decoded Java symbol names for that process. As this just writes a snapshot of the code cache when the command is run, it will become stale if methods are compiled later or unloaded. However this shouldn't be a big problem in practice if the map file is generated after the application has warmed up. [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt [2] https://github.com/jvm-profiling-tools/perf-map-agent ------------- Commit messages: - 8254723: add diagnostic command to write Linux perf map file Changes: https://git.openjdk.java.net/jdk/pull/760/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=760&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254723 Stats: 149 lines in 5 files changed: 148 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/760.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/760/head:pull/760 PR: https://git.openjdk.java.net/jdk/pull/760 From shade at openjdk.java.net Tue Oct 20 09:45:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 20 Oct 2020 09:45:20 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 18:13:59 GMT, Vladimir Kozlov wrote: >> Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. > > Always run graalunit testing with new intrinsics. > You need to adjust Graal test: > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java I just ran `CONF=linux-x86_64-server-fastdebug make clean run-test TEST=compiler/graalunit` without problems even without the `CheckGraalIntrinsics.java` changes. Does the test actually work? ------------- PR: https://git.openjdk.java.net/jdk/pull/650 From rehn at openjdk.java.net Tue Oct 20 09:56:12 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Oct 2020 09:56:12 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended In-Reply-To: References: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> Message-ID: On Tue, 20 Oct 2020 07:12:01 GMT, Robbin Ehn wrote: >> Hi Robbin, >> >> IIUC the "waiting" part of `wait_for_ext_suspend_completion` is now implicitly handled in the handshake - correct? >> >> Overall this seems like a great simplification. >> >> A few minor comments below. >> >> Thanks, >> David > > Hi David, thanks for having a look. > >> Hi Robbin, >> >> IIUC the "waiting" part of `wait_for_ext_suspend_completion` is now implicitly handled in the handshake - correct? > > A suspended Java thread may never transition back to java, never execute any more bytecodes. > The old 'fully' suspended gives more guarantees which we need to do some operations. > When we are in a handshake, the handshake gives us those guarantees, so it is enough that thread is considered > suspended. > So the answer is we wait until we are allowed to execute those operations (thread handshake safe), which is not > identical with fully suspended. But fully suspended is an implementation detail, the agent only knows about suspended. >> >> Overall this seems like a great simplification. >> >> A few minor comments below. >> >> Thanks, >> David > Not clear to me this is so generic that it applies to Handshake::execute > rather than being part of the operation. ?? We only have two other cases (other than JVM TI where we always do this). This one, async exception: if (thread == receiver) { // Exception is getting thrown at self so no VM_Operation needed. THROW_OOP(java_throwable); } else { // Use a VM_Operation to throw the exception. Thread::send_async_exception(java_thread, java_throwable); } And biased locking revoke where we don't do this, because it makes no sense revoking a lock if you have the bias :) In that case we could assert we never try to revoke a self owned bias. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From shade at openjdk.java.net Tue Oct 20 10:24:35 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 20 Oct 2020 10:24:35 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v4] In-Reply-To: References: Message-ID: > This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like > this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to > `Instrumentation`, and let the tools use that fast path today. With this patch, JOL is able to be close to > `deepSizeOf` implementation from SizeOf JEP. > Example performance improvements for sizing up a custom linked list: > > Benchmark (size) Mode Cnt Score Error Units > > # Default > LinkedChainBench.linkedChain 1 avgt 5 705.835 ? 8.051 ns/op > LinkedChainBench.linkedChain 10 avgt 5 3148.874 ? 37.856 ns/op > LinkedChainBench.linkedChain 100 avgt 5 28693.256 ? 142.254 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 290161.590 ? 4594.631 ns/op > > # Instrumentation attached, no intrinsics > LinkedChainBench.linkedChain 1 avgt 5 159.659 ? 19.238 ns/op > LinkedChainBench.linkedChain 10 avgt 5 717.659 ? 22.540 ns/op > LinkedChainBench.linkedChain 100 avgt 5 7739.394 ? 111.683 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 80724.238 ? 2887.794 ns/op > > # Instrumentation attached, new intrinsics > LinkedChainBench.linkedChain 1 avgt 5 95.254 ? 0.808 ns/op > LinkedChainBench.linkedChain 10 avgt 5 261.564 ? 8.524 ns/op > LinkedChainBench.linkedChain 100 avgt 5 3367.192 ? 21.128 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 34148.851 ? 373.080 ns/op Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Add new intrinsics to toBeInvestigated list in CheckGraalIntrinsics.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/650/files - new: https://git.openjdk.java.net/jdk/pull/650/files/6160f6a8..132f2c50 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=02-03 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/650.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/650/head:pull/650 PR: https://git.openjdk.java.net/jdk/pull/650 From shade at openjdk.java.net Tue Oct 20 10:24:35 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 20 Oct 2020 10:24:35 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 18:13:59 GMT, Vladimir Kozlov wrote: >> Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. > > Always run graalunit testing with new intrinsics. > You need to adjust Graal test: > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java @vnkozlov I added the new block in `CheckGraalIntrinsics.java`, and made sure it passes the entire `compiler/graalunit` with [JDK-8254785](https://bugs.openjdk.java.net/browse/JDK-8254785) applied. ------------- PR: https://git.openjdk.java.net/jdk/pull/650 From rehn at openjdk.java.net Tue Oct 20 10:32:26 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Oct 2020 10:32:26 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: References: Message-ID: <5R147e7WLawIyLWxjBQUNK22Y19rDsT32HYDCUXep7g=.a2344642-ca05-429e-a733-4ead81eb4f20@github.com> > The main point of this change-set is to make it easier to implement S/R on top of handshakes. > Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). > But we also remove some complicated S/R methods. > > We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. > > TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. > But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. > > Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision: - Removed TraceSuspendDebugBits - Removed unused method is_ext_suspend_completed_with_lock ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/729/files - new: https://git.openjdk.java.net/jdk/pull/729/files/7e77a04f..386b930f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=729&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=729&range=00-01 Stats: 94 lines in 2 files changed: 0 ins; 88 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/729/head:pull/729 PR: https://git.openjdk.java.net/jdk/pull/729 From shade at openjdk.java.net Tue Oct 20 10:55:09 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 20 Oct 2020 10:55:09 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file In-Reply-To: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Tue, 20 Oct 2020 09:27:45 GMT, Nick Gasson wrote: > When using the Linux "perf" tool to do system profiling, symbol names of > running Java methods cannot be decoded, resulting in unhelpful output > such as: > > 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 > > Perf can read a simple text file format describing the mapping between > address ranges and symbol names for a particular process [1]. > > It's possible to generate this already for Java processes using a JVMTI > plugin such as perf-map-agent [2]. However this requires compiling > third-party code and then loading the agent into your Java process. It > would be more convenient if Hotspot could write this file directly using > a diagnostic command. The information required is almost identical to > that of the existing Compiler.codelist command. > > This patch adds a Compiler.perfmap diagnostic command on Linux only. To > use, first run "jcmd Compiler.perfmap" and then "perf top" or > "perf record" and the report should show decoded Java symbol names for > that process. > > As this just writes a snapshot of the code cache when the command is > run, it will become stale if methods are compiled later or unloaded. > However this shouldn't be a big problem in practice if the map file is > generated after the application has warmed up. > > [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt > [2] https://github.com/jvm-profiling-tools/perf-map-agent That's a nifty idea! (Kicks himself for not coming up with it myself.) I do wonder the UX would be better to dump the map file at VM shutdown (guarded by flag, sigh). Because it seems that for the short jobs, we would like to just do "perf record java -XX:+WhatEver", followed by "perf report", without requiring user to invoke the diagnostic command while JVM is still running? test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 60: > 58: static Pattern outputPattern = > 59: Pattern.compile("Written to (/tmp/perf-\\p{Digit}*\\.map)"); > 60: static Pattern linePattern = `static final Pattern OUTPUT_PATTERN` and `static final Pattern LINE_PATTERN` here? test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 79: > 77: } catch (FileNotFoundException e) { > 78: Assert.fail(e.toString()); > 79: } Sounds like a lot of this scaffolding could be replaced by `for (String line : Files.readAllLines(m.group(1))) { ... }`? ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From github.com+213894+vlsi at openjdk.java.net Tue Oct 20 11:46:27 2020 From: github.com+213894+vlsi at openjdk.java.net (Vladimir Sitnikov) Date: Tue, 20 Oct 2020 11:46:27 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file In-Reply-To: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Tue, 20 Oct 2020 09:27:45 GMT, Nick Gasson wrote: > When using the Linux "perf" tool to do system profiling, symbol names of > running Java methods cannot be decoded, resulting in unhelpful output > such as: > > 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 > > Perf can read a simple text file format describing the mapping between > address ranges and symbol names for a particular process [1]. > > It's possible to generate this already for Java processes using a JVMTI > plugin such as perf-map-agent [2]. However this requires compiling > third-party code and then loading the agent into your Java process. It > would be more convenient if Hotspot could write this file directly using > a diagnostic command. The information required is almost identical to > that of the existing Compiler.codelist command. > > This patch adds a Compiler.perfmap diagnostic command on Linux only. To > use, first run "jcmd Compiler.perfmap" and then "perf top" or > "perf record" and the report should show decoded Java symbol names for > that process. > > As this just writes a snapshot of the code cache when the command is > run, it will become stale if methods are compiled later or unloaded. > However this shouldn't be a big problem in practice if the map file is > generated after the application has warmed up. > > [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt > [2] https://github.com/jvm-profiling-tools/perf-map-agent test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 68: > 66: Matcher m = outputPattern.matcher(line); > 67: > 68: Assert.assertTrue(m.matches(), "Did not print map file name"); Suggestion: Assert.assertTrue(m.matches(), "Did not print map file name, line = " + line); ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From dholmes at openjdk.java.net Tue Oct 20 11:58:22 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 20 Oct 2020 11:58:22 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: <5R147e7WLawIyLWxjBQUNK22Y19rDsT32HYDCUXep7g=.a2344642-ca05-429e-a733-4ead81eb4f20@github.com> References: <5R147e7WLawIyLWxjBQUNK22Y19rDsT32HYDCUXep7g=.a2344642-ca05-429e-a733-4ead81eb4f20@github.com> Message-ID: On Tue, 20 Oct 2020 10:32:26 GMT, Robbin Ehn wrote: >> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >> But we also remove some complicated S/R methods. >> >> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >> >> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >> >> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. > > Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision: > > - Removed TraceSuspendDebugBits > - Removed unused method is_ext_suspend_completed_with_lock Still looks good. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Tue Oct 20 12:56:22 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Oct 2020 12:56:22 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: References: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> Message-ID: On Tue, 20 Oct 2020 12:06:57 GMT, Coleen Phillimore wrote: >> Yes, that would be good. > > Why don't you just do: > JavaThread* java_thread = JavaThread::current(); > HandleMark hm(java_thread); > > JavaThread::current is the same thing as what you have. Hi Coleen, we are in a handshake. Target java_thread must be treat as different from current thread. It can be same, but also another thread java thread or VM thread. So we only know the the thread executing is a Thread, but our target is a JavaThread. Here we want to create a HandleMark in current thread. Then we want a JavaThread pointer to the target for later use. Does that explain it? ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Tue Oct 20 14:13:21 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 20 Oct 2020 14:13:21 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: References: <5R147e7WLawIyLWxjBQUNK22Y19rDsT32HYDCUXep7g=.a2344642-ca05-429e-a733-4ead81eb4f20@github.com> Message-ID: <010C_PcZp7Ol1SpH7__fIb5SPJrbFaQMUa0DN_R2rtM=.49983d69-0901-4081-9043-fbfaef0e4c61@github.com> On Tue, 20 Oct 2020 11:55:49 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision: >> >> - Removed TraceSuspendDebugBits >> - Removed unused method is_ext_suspend_completed_with_lock > > Still looks good. Hi, this is a good change, because it is a simplification and it it makes the stack walks safe by doing them as part of a handshake. The change conflicts with #119 though. This one is ready to be pushed since last week but was delayed due to other interferences. Would you mind me integrating #119 first? After integration it would be needed to pull 2 EscapeBarriers out of handshakes. Of course I would help do that. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From coleenp at openjdk.java.net Tue Oct 20 14:17:17 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 20 Oct 2020 14:17:17 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: References: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> Message-ID: On Tue, 20 Oct 2020 12:53:15 GMT, Robbin Ehn wrote: >> Why don't you just do: >> JavaThread* java_thread = JavaThread::current(); >> HandleMark hm(java_thread); >> >> JavaThread::current is the same thing as what you have. >> >> Oh I see there are two different threads. nevermind. > > Hi Coleen, we are in a handshake. > Target java_thread must be treat as different from current thread. > It can be same, but also another thread java thread or VM thread. > So we only know the the thread executing is a Thread, but our target is a JavaThread. > > Here we want to create a HandleMark in current thread. > Then we want a JavaThread pointer to the target for later use. > > Does that explain it? I see it now, different threads. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Tue Oct 20 14:22:23 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Oct 2020 14:22:23 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: <010C_PcZp7Ol1SpH7__fIb5SPJrbFaQMUa0DN_R2rtM=.49983d69-0901-4081-9043-fbfaef0e4c61@github.com> References: <5R147e7WLawIyLWxjBQUNK22Y19rDsT32HYDCUXep7g=.a2344642-ca05-429e-a733-4ead81eb4f20@github.com> <010C_PcZp7Ol1SpH7__fIb5SPJrbFaQMUa0DN_R2rtM=.49983d69-0901-4081-9043-fbfaef0e4c61@github.com> Message-ID: On Tue, 20 Oct 2020 14:10:49 GMT, Richard Reingruber wrote: > Hi, > > this is a good change, because it is a simplification and it it makes the stack walks safe by doing them as part of a > handshake. > The change conflicts with #119 though. This one is ready to be pushed since last week but was delayed due to other > interferences. Would you mind me integrating #119 first? After integration it would be needed to pull 2 EscapeBarriers > out of handshakes. Of course I would help do that. Thanks, Richard. Hey Richard, go ahead and integrate your 119 first, I'll hold off and do the merge once you integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Tue Oct 20 15:36:19 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 20 Oct 2020 15:36:19 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: References: <5R147e7WLawIyLWxjBQUNK22Y19rDsT32HYDCUXep7g=.a2344642-ca05-429e-a733-4ead81eb4f20@github.com> <010C_PcZp7Ol1SpH7__fIb5SPJrbFaQMUa0DN_R2rtM=.49983d69-0901-4081-9043-fbfaef0e4c61@github.com> Message-ID: On Tue, 20 Oct 2020 14:18:57 GMT, Robbin Ehn wrote: > > > > Hi, > > this is a good change, because it is a simplification and it it makes the stack walks safe by doing them as part of a > > handshake. The change conflicts with #119 though. This one is ready to be pushed since last week but was delayed due to > > other interferences. Would you mind me integrating #119 first? After integration it would be needed to pull 2 > > EscapeBarriers out of handshakes. Of course I would help do that. Thanks, Richard. > > Hey Richard, go ahead and integrate your 119 first, I'll hold off and do the merge once you integrated. Thanks Robbin! ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Tue Oct 20 15:38:18 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 20 Oct 2020 15:38:18 GMT Subject: Integrated: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 20:48:23 GMT, Richard Reingruber wrote: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. This pull request has now been integrated. Changeset: 40f847e2 Author: Richard Reingruber URL: https://git.openjdk.java.net/jdk/commit/40f847e2 Stats: 5860 lines in 53 files changed: 5642 ins; 116 del; 102 mod 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement Reviewed-by: mdoerr, goetz, sspitsyn, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From kvn at openjdk.java.net Tue Oct 20 17:41:20 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 20 Oct 2020 17:41:20 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3] In-Reply-To: References: Message-ID: <0E5sXAWBENg290o8HpKfufH-e69Ue4EfAR074HuNOt4=.3e8af6ad-4aaf-4427-b008-642ca7138f02@github.com> On Mon, 19 Oct 2020 06:57:24 GMT, Aleksey Shipilev wrote: >> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like >> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to >> `Instrumentation`, and let the tools use that fast path today. With this patch, JOL is able to be close to >> `deepSizeOf` implementation from SizeOf JEP. >> Example performance improvements for sizing up a custom linked list: >> >> Benchmark (size) Mode Cnt Score Error Units >> >> # Default >> LinkedChainBench.linkedChain 1 avgt 5 705.835 ? 8.051 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 3148.874 ? 37.856 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 28693.256 ? 142.254 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 290161.590 ? 4594.631 ns/op >> >> # Instrumentation attached, no intrinsics >> LinkedChainBench.linkedChain 1 avgt 5 159.659 ? 19.238 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 717.659 ? 22.540 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 7739.394 ? 111.683 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 80724.238 ? 2887.794 ns/op >> >> # Instrumentation attached, new intrinsics >> LinkedChainBench.linkedChain 1 avgt 5 95.254 ? 0.808 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 261.564 ? 8.524 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 3367.192 ? 21.128 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 34148.851 ? 373.080 ns/op > > Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. test/jdk/java/lang/instrument/GetObjectSizeTest.java line 2: > 1: /* > 2: * Copyright (c) 2020, Red Hat, Inc. All rights reserved. You can't replace Copyright lines of one company with other. ------------- PR: https://git.openjdk.java.net/jdk/pull/650 From kvn at openjdk.java.net Tue Oct 20 17:41:19 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 20 Oct 2020 17:41:19 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v4] In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 10:24:35 GMT, Aleksey Shipilev wrote: >> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like >> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to >> `Instrumentation`, and let the tools use that fast path today. With this patch, JOL is able to be close to >> `deepSizeOf` implementation from SizeOf JEP. >> Example performance improvements for sizing up a custom linked list: >> >> Benchmark (size) Mode Cnt Score Error Units >> >> # Default >> LinkedChainBench.linkedChain 1 avgt 5 705.835 ? 8.051 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 3148.874 ? 37.856 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 28693.256 ? 142.254 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 290161.590 ? 4594.631 ns/op >> >> # Instrumentation attached, no intrinsics >> LinkedChainBench.linkedChain 1 avgt 5 159.659 ? 19.238 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 717.659 ? 22.540 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 7739.394 ? 111.683 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 80724.238 ? 2887.794 ns/op >> >> # Instrumentation attached, new intrinsics >> LinkedChainBench.linkedChain 1 avgt 5 95.254 ? 0.808 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 261.564 ? 8.524 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 3367.192 ? 21.128 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 34148.851 ? 373.080 ns/op > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Add new intrinsics to toBeInvestigated list in CheckGraalIntrinsics.java Changes requested by kvn (Reviewer). src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java line 531: > 529: "sun/instrument/InstrumentationImpl.getObjectSize0(JLjava/lang/Object;)J"); > 530: } > 531: Agree with this. ------------- PR: https://git.openjdk.java.net/jdk/pull/650 From shade at openjdk.java.net Tue Oct 20 17:46:18 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 20 Oct 2020 17:46:18 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3] In-Reply-To: References: <0E5sXAWBENg290o8HpKfufH-e69Ue4EfAR074HuNOt4=.3e8af6ad-4aaf-4427-b008-642ca7138f02@github.com> Message-ID: On Tue, 20 Oct 2020 17:42:00 GMT, Aleksey Shipilev wrote: >> test/jdk/java/lang/instrument/GetObjectSizeTest.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2020, Red Hat, Inc. All rights reserved. >> >> You can't replace Copyright lines of one company with other. > > Well, I am replacing the entire file. There is a recent precedent of the similar change > [here](https://github.com/openjdk/jdk/commit/6d13c766#diff-0daf75421f8fdb55a5640742ef6f12730fe1b370cc864311c188ad99996b51fe). > Either that should be reversed, or this one accepted. ...or I can put new test into a separate file. But the existing test is quite inferior compared to the new one, so it does not seem to make a lot of sense to keep it. ------------- PR: https://git.openjdk.java.net/jdk/pull/650 From shade at openjdk.java.net Tue Oct 20 17:46:18 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 20 Oct 2020 17:46:18 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3] In-Reply-To: <0E5sXAWBENg290o8HpKfufH-e69Ue4EfAR074HuNOt4=.3e8af6ad-4aaf-4427-b008-642ca7138f02@github.com> References: <0E5sXAWBENg290o8HpKfufH-e69Ue4EfAR074HuNOt4=.3e8af6ad-4aaf-4427-b008-642ca7138f02@github.com> Message-ID: On Tue, 20 Oct 2020 17:33:56 GMT, Vladimir Kozlov wrote: >> Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. > > test/jdk/java/lang/instrument/GetObjectSizeTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2020, Red Hat, Inc. All rights reserved. > > You can't replace Copyright lines of one company with other. Well, I am replacing the entire file. There is a recent precedent of the similar change [here](https://github.com/openjdk/jdk/commit/6d13c766#diff-0daf75421f8fdb55a5640742ef6f12730fe1b370cc864311c188ad99996b51fe). Either that should be reversed, or this one accepted. ------------- PR: https://git.openjdk.java.net/jdk/pull/650 From rrich at openjdk.java.net Tue Oct 20 17:56:14 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 20 Oct 2020 17:56:14 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: References: <5R147e7WLawIyLWxjBQUNK22Y19rDsT32HYDCUXep7g=.a2344642-ca05-429e-a733-4ead81eb4f20@github.com> <010C_PcZp7Ol1SpH7__fIb5SPJrbFaQMUa0DN_R2rtM=.49983d69-0901-4081-9043-fbfaef0e4c61@github.com> Message-ID: <-vefsX3p5IkTBZvrIepZdJ-Q1G9HoSDsyVj2M3dkyKc=.03e18d1d-341f-45cc-a25b-c2894ae373e8@github.com> On Tue, 20 Oct 2020 15:33:59 GMT, Richard Reingruber wrote: >>> Hi, >>> >>> this is a good change, because it is a simplification and it it makes the stack walks safe by doing them as part of a >>> handshake. >>> The change conflicts with #119 though. This one is ready to be pushed since last week but was delayed due to other >>> interferences. Would you mind me integrating #119 first? After integration it would be needed to pull 2 EscapeBarriers >>> out of handshakes. Of course I would help do that. Thanks, Richard. >> >> Hey Richard, go ahead and integrate your 119 first, I'll hold off and do the merge once you integrated. > >> >> >> > Hi, >> > this is a good change, because it is a simplification and it it makes the stack walks safe by doing them as part of a >> > handshake. The change conflicts with #119 though. This one is ready to be pushed since last week but was delayed due to >> > other interferences. Would you mind me integrating #119 first? After integration it would be needed to pull 2 >> > EscapeBarriers out of handshakes. Of course I would help do that. Thanks, Richard. >> >> Hey Richard, go ahead and integrate your 119 first, I'll hold off and do the merge once you integrated. > > Thanks Robbin! Hi Robbin, for merging master after integration of #119 I'd suggest to resolve the conflicts by chosing the alternative from this pr and then apply https://github.com/reinrich/jdk/commit/6fa91e344ed5bf6d877e3f5a2d0d1920591fd441 (is there a more elegant way to propose a patch?) I successfully tested make run-test TEST=test/jdk/com/sun/jdi/EATests.java which also covers PopFrame and ForceEarlyReturn. More tests are running. For night tests of our team it is unfortunately too late. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From kvn at openjdk.java.net Tue Oct 20 17:57:13 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 20 Oct 2020 17:57:13 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3] In-Reply-To: References: <0E5sXAWBENg290o8HpKfufH-e69Ue4EfAR074HuNOt4=.3e8af6ad-4aaf-4427-b008-642ca7138f02@github.com> Message-ID: On Tue, 20 Oct 2020 17:43:07 GMT, Aleksey Shipilev wrote: >> Well, I am replacing the entire file. There is a recent precedent of the similar change >> [here](https://github.com/openjdk/jdk/commit/6d13c766#diff-0daf75421f8fdb55a5640742ef6f12730fe1b370cc864311c188ad99996b51fe). >> Either that should be reversed, or this one accepted. > > ...or I can put new test into a separate file. But the existing test is quite inferior compared to the new one, so it > does not seem to make a lot of sense to keep it. It was mistake in 8253191 (I file bug). If you modify existing file (even if you keep only test name the same) you have to preserve original Copyright and add new Copyright line. You don't need create new file. We have a lot of cases with 2 or more Copyright lines - it is normal: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/vectorization/TestVectorsNotSavedAtSafepoint.java ------------- PR: https://git.openjdk.java.net/jdk/pull/650 From kvn at openjdk.java.net Tue Oct 20 18:15:13 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 20 Oct 2020 18:15:13 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3] In-Reply-To: References: <0E5sXAWBENg290o8HpKfufH-e69Ue4EfAR074HuNOt4=.3e8af6ad-4aaf-4427-b008-642ca7138f02@github.com> Message-ID: On Tue, 20 Oct 2020 17:54:21 GMT, Vladimir Kozlov wrote: >> ...or I can put new test into a separate file. But the existing test is quite inferior compared to the new one, so it >> does not seem to make a lot of sense to keep it. > > It was mistake in 8253191 (I file bug). If you modify existing file (even if you keep only test name the same) you have > to preserve original Copyright and add new Copyright line. You don't need create new file. We have a lot of cases with > 2 or more Copyright lines - it is normal: > https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/vectorization/TestVectorsNotSavedAtSafepoint.java I file 8255067 to restore Copyright line in TestUnsignedByteCompare.java test file. ------------- PR: https://git.openjdk.java.net/jdk/pull/650 From rehn at openjdk.java.net Tue Oct 20 19:45:17 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Oct 2020 19:45:17 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: <-vefsX3p5IkTBZvrIepZdJ-Q1G9HoSDsyVj2M3dkyKc=.03e18d1d-341f-45cc-a25b-c2894ae373e8@github.com> References: <5R147e7WLawIyLWxjBQUNK22Y19rDsT32HYDCUXep7g=.a2344642-ca05-429e-a733-4ead81eb4f20@github.com> <010C_PcZp7Ol1SpH7__fIb5SPJrbFaQMUa0DN_R2rtM=.49983d69-0901-4081-9043-fbfaef0e4c61@github.com> <-vefsX3p5IkTBZvrIepZdJ-Q1G9HoSDsyVj2M3dkyKc=.03e18d1d-341f-45cc-a25b-c2894ae373e8@github.com> Message-ID: <_akbNkG-trhkT8U9QefeEYexY06Ztv6F2HiFHZF3alI=.d7f4266e-1460-433c-8e20-8dea52d927aa@github.com> On Tue, 20 Oct 2020 17:53:47 GMT, Richard Reingruber wrote: >>> >>> >>> > Hi, >>> > this is a good change, because it is a simplification and it it makes the stack walks safe by doing them as part of a >>> > handshake. The change conflicts with #119 though. This one is ready to be pushed since last week but was delayed due to >>> > other interferences. Would you mind me integrating #119 first? After integration it would be needed to pull 2 >>> > EscapeBarriers out of handshakes. Of course I would help do that. Thanks, Richard. >>> >>> Hey Richard, go ahead and integrate your 119 first, I'll hold off and do the merge once you integrated. >> >> Thanks Robbin! > > Hi Robbin, > > for merging master after integration of #119 I'd suggest to resolve the > conflicts by chosing the alternative from this pr and then apply > https://github.com/reinrich/jdk/commit/6fa91e344ed5bf6d877e3f5a2d0d1920591fd441 > (is there a more elegant way to propose a patch?) > > I successfully tested > > make run-test TEST=test/jdk/com/sun/jdi/EATests.java > which also covers PopFrame and ForceEarlyReturn. > > More tests are running. > > For night tests of our team it is unfortunately too late. > > Thanks, Richard. Thanks, I'm exploring what we need to execute the EB inside the handshake. So far I think that really needs to go in a separate PR, since it becomes really unrelated to this.... picking up your change. > Hi Robbin, > > for merging master after integration of #119 I'd suggest to resolve the > conflicts by chosing the alternative from this pr and then apply > [reinrich at 6fa91e3](https://github.com/reinrich/jdk/commit/6fa91e344ed5bf6d877e3f5a2d0d1920591fd441) > (is there a more elegant way to propose a patch?) > > I successfully tested > > ``` > make run-test TEST=test/jdk/com/sun/jdi/EATests.java > ``` > > which also covers PopFrame and ForceEarlyReturn. > > More tests are running. > > For night tests of our team it is unfortunately too late. > > Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Tue Oct 20 19:57:08 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 20 Oct 2020 19:57:08 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: <_akbNkG-trhkT8U9QefeEYexY06Ztv6F2HiFHZF3alI=.d7f4266e-1460-433c-8e20-8dea52d927aa@github.com> References: <5R147e7WLawIyLWxjBQUNK22Y19rDsT32HYDCUXep7g=.a2344642-ca05-429e-a733-4ead81eb4f20@github.com> <010C_PcZp7Ol1SpH7__fIb5SPJrbFaQMUa0DN_R2rtM=.49983d69-0901-4081-9043-fbfaef0e4c61@github.com> <-vefsX3p5IkTBZvrIepZdJ-Q1G9HoSDsyVj2M3dkyKc=.03e18d1d-341f-45cc-a25b-c2894ae373e8@github.com> <_akbNkG-trhkT8U9QefeEYexY06Ztv6F2HiFHZF3alI=.d7f4266e-1460-433c-8e20-8dea52d927aa@github.com> Message-ID: On Tue, 20 Oct 2020 19:42:38 GMT, Robbin Ehn wrote: > Thanks, I'm exploring what we need to execute the EB inside the handshake. I want to experiment with object reallocation without referencing a frame. I think a should be possible to reallocate objects given only the corresponding compiled pc. If so, then a handshake/vm operation can fail with the request to reallocate objects at a pc. This can be done concurrently and then the handshake/vm operation can be restarted. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From iignatyev at openjdk.java.net Tue Oct 20 20:22:18 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 20 Oct 2020 20:22:18 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 01:13:33 GMT, Chris Plummer wrote: >> although horizontal alignment (of variable names, initialization, expressions, etc) seems to somewhat improve >> readability, it almost always associated with a higher maintenance cost, and the current consensus is not to do that. >> from 'Horizontal Whitespace' section of the same >> [guidelines](http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-whitespace): >>> In variable declarations it is not recommended to align types and variables. >> *Motivation* >> The improvement in readability when aligning variable names is negligible compared to the efforts needed to keep them >> aligned as the code evolves. Realigning all variables when one of the types change also causes unnecessarily >> complicated patches to review. other java code guidelines either discourage horizontal alignment or consider it >> optional and provide the same motivation as above to why it's better not to have it. > > While in general I agree that gratuitous aligning of variables is not desirable, this is a special case where it adds > value (enough that I think it's worth doing). The value here is due to the fact that the variables are building on each > other. When they are aligned it's easier to scan for the variable (and its value) that another variable builds on. You > can keep your change in place if you feel that consistency and maintainabilty is more important here than readability. Although I don't think that the test code has the same frequency of changes as the product code, I'd still prefer consistency and maintainability over some small penalty (which is IMHO negligible) in readability. frankly, it's also partially motivated by my laziness as I don't want to go over all these files again and examine each and every initialization for possible (scanty) readability improvements from horizontal alignment. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From rrich at openjdk.java.net Tue Oct 20 22:09:16 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 20 Oct 2020 22:09:16 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown Message-ID: The following test cases try to provoke VMOutOfMemoryException during object reallocation: EAPopFrameNotInlinedReallocFailure EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure This is not 100% reliable therefore it should not be treated as test failure if no oom was raised. ------------- Commit messages: - 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown Changes: https://git.openjdk.java.net/jdk/pull/775/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255072 Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/775/head:pull/775 PR: https://git.openjdk.java.net/jdk/pull/775 From cjplummer at openjdk.java.net Tue Oct 20 22:48:10 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 20 Oct 2020 22:48:10 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown In-Reply-To: References: Message-ID: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> On Tue, 20 Oct 2020 21:53:10 GMT, Richard Reingruber wrote: > The following test cases try to provoke VMOutOfMemoryException during object reallocation: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > This is not 100% reliable therefore it should not be treated as test failure if no oom was raised. If the test does not throw OOME, has it actually tested anything in that case? My concern with any test that allows for what is suppose to be an occasional failure it that it will not detect if something breaks and causes that failure to happen every time, often rendering the test useless. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From cjplummer at openjdk.java.net Tue Oct 20 22:52:18 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 20 Oct 2020 22:52:18 GMT Subject: RFR: 6606767: resexhausted00[34] fail assert(!thread->owns_locks(), "must release all locks when leaving VM") In-Reply-To: References: Message-ID: <8mIMvfs4cy-CfZiwvkSosbpmcEr2TYk-oX9Oj1BYb4A=.c006dbe9-1e7c-4c5d-b480-089dd86e4240@github.com> On Wed, 14 Oct 2020 22:25:34 GMT, Alex Menkov wrote: > Please review the fix for JDK-6606767. > The original issue is not reproducible. > The fix: > - resexhausted003 and resexhausted004 are un-problemlisted > - resexhausted004 is problemlisted on linux due JDK-8253916 (resexhausted004 executes > resexhausted001/resexhausted002/resexhausted003 randomly, and resexhausted001 fails on linux) > - resexhausted003 is updated to throw SkippedException if OOME is not thrown; > - resexhausted004 is updated to catch SkippedException from resexhausted001..003, also logic is slightly simplified Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/671 From ysuenaga at openjdk.java.net Wed Oct 21 04:38:09 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 21 Oct 2020 04:38:09 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file In-Reply-To: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Tue, 20 Oct 2020 09:27:45 GMT, Nick Gasson wrote: > When using the Linux "perf" tool to do system profiling, symbol names of > running Java methods cannot be decoded, resulting in unhelpful output > such as: > > 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 > > Perf can read a simple text file format describing the mapping between > address ranges and symbol names for a particular process [1]. > > It's possible to generate this already for Java processes using a JVMTI > plugin such as perf-map-agent [2]. However this requires compiling > third-party code and then loading the agent into your Java process. It > would be more convenient if Hotspot could write this file directly using > a diagnostic command. The information required is almost identical to > that of the existing Compiler.codelist command. > > This patch adds a Compiler.perfmap diagnostic command on Linux only. To > use, first run "jcmd Compiler.perfmap" and then "perf top" or > "perf record" and the report should show decoded Java symbol names for > that process. > > As this just writes a snapshot of the code cache when the command is > run, it will become stale if methods are compiled later or unloaded. > However this shouldn't be a big problem in practice if the map file is > generated after the application has warmed up. > > [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt > [2] https://github.com/jvm-profiling-tools/perf-map-agent Changes requested by ysuenaga (Reviewer). src/hotspot/share/services/diagnosticCommand.hpp line 589: > 587: return "Write map file for Linux perf tool."; > 588: } > 589: static const char* impact() { This operation does not seems to happen in Safepoint. It can be defined as "Low" IMHO. src/hotspot/share/code/codeCache.cpp line 1562: > 1560: } > 1561: > 1562: void CodeCache::write_perf_map(outputStream* st) { Should this code (and changes in header files) be included for Linux only? (`#ifdef LINUX` like the change in diagnosticCommand.cpp) src/hotspot/share/code/codeCache.cpp line 1570: > 1568: fileStream fs(fname, "w"); > 1569: if (!fs.is_open()) { > 1570: st->print_cr("Failed to create %s", fname); This message should be used Unified Logging. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From rehn at openjdk.java.net Wed Oct 21 08:40:49 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 21 Oct 2020 08:40:49 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: References: <5R147e7WLawIyLWxjBQUNK22Y19rDsT32HYDCUXep7g=.a2344642-ca05-429e-a733-4ead81eb4f20@github.com> <010C_PcZp7Ol1SpH7__fIb5SPJrbFaQMUa0DN_R2rtM=.49983d69-0901-4081-9043-fbfaef0e4c61@github.com> <-vefsX3p5IkTBZvrIepZdJ-Q1G9HoSDsyVj2M3dkyKc=.03e18d1d-341f-45cc-a25b-c2894ae373e8@github.com> <_akbNkG-trhkT8U9QefeEYexY06Ztv6F2HiFHZF3alI=.d7f4266e-1460-433c-8e20-8dea52d927aa@github.com> Message-ID: On Tue, 20 Oct 2020 19:54:06 GMT, Richard Reingruber wrote: >> Thanks, I'm exploring what we need to execute the EB inside the handshake. >> So far I think that really needs to go in a separate PR, since it becomes really unrelated to this.... picking up your change. >> >>> Hi Robbin, >>> >>> for merging master after integration of #119 I'd suggest to resolve the >>> conflicts by chosing the alternative from this pr and then apply >>> [reinrich at 6fa91e3](https://github.com/reinrich/jdk/commit/6fa91e344ed5bf6d877e3f5a2d0d1920591fd441) >>> (is there a more elegant way to propose a patch?) >>> >>> I successfully tested >>> >>> ``` >>> make run-test TEST=test/jdk/com/sun/jdi/EATests.java >>> ``` >>> >>> which also covers PopFrame and ForceEarlyReturn. >>> >>> More tests are running. >>> >>> For night tests of our team it is unfortunately too late. >>> >>> Thanks, Richard. > >> Thanks, I'm exploring what we need to execute the EB inside the handshake. > > I want to experiment with object reallocation without referencing a frame. I think a should be possible to reallocate objects given only the corresponding compiled pc. If so, then a handshake/vm operation can fail with the request to reallocate objects at a pc. This can be done concurrently and then the handshake/vm operation can be restarted. I pushed the merge. (I manage to pick up bad state in first merge, so I did a second merge to get the fixes for that) Please have a look. Still running test, but there were some interest in this change-set (it seem to fix an unrelated bug also) so I published it. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Wed Oct 21 08:40:47 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 21 Oct 2020 08:40:47 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: > The main point of this change-set is to make it easier to implement S/R on top of handshakes. > Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). > But we also remove some complicated S/R methods. > > We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. > > TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. > But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. > > Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Fixed merge miss - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended - Merge fix from Richard - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended - Removed TraceSuspendDebugBits - Removed unused method is_ext_suspend_completed_with_lock - Utilize handshakes instead of is_thread_fully_suspended ------------- Changes: https://git.openjdk.java.net/jdk/pull/729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=729&range=02 Stats: 606 lines in 6 files changed: 182 ins; 371 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/729/head:pull/729 PR: https://git.openjdk.java.net/jdk/pull/729 From ngasson at openjdk.java.net Wed Oct 21 09:13:08 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 21 Oct 2020 09:13:08 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: > When using the Linux "perf" tool to do system profiling, symbol names of > running Java methods cannot be decoded, resulting in unhelpful output > such as: > > 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 > > Perf can read a simple text file format describing the mapping between > address ranges and symbol names for a particular process [1]. > > It's possible to generate this already for Java processes using a JVMTI > plugin such as perf-map-agent [2]. However this requires compiling > third-party code and then loading the agent into your Java process. It > would be more convenient if Hotspot could write this file directly using > a diagnostic command. The information required is almost identical to > that of the existing Compiler.codelist command. > > This patch adds a Compiler.perfmap diagnostic command on Linux only. To > use, first run "jcmd Compiler.perfmap" and then "perf top" or > "perf record" and the report should show decoded Java symbol names for > that process. > > As this just writes a snapshot of the code cache when the command is > run, it will become stale if methods are compiled later or unloaded. > However this shouldn't be a big problem in practice if the map file is > generated after the application has warmed up. > > [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt > [2] https://github.com/jvm-profiling-tools/perf-map-agent Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: Update for review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/760/files - new: https://git.openjdk.java.net/jdk/pull/760/files/5b0c2695..a3cb0ed4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=760&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=760&range=00-01 Stats: 16 lines in 3 files changed: 1 ins; 2 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/760.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/760/head:pull/760 PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Wed Oct 21 09:13:09 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 21 Oct 2020 09:13:09 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Tue, 20 Oct 2020 10:52:27 GMT, Aleksey Shipilev wrote: > > Because it seems that for the short jobs, we would like to just do "perf record java -XX:+WhatEver", followed by "perf report", without requiring user to invoke the diagnostic command while JVM is still running? Yes that sounds like a good idea. Add a (diagnostic?) option `-XX:+WritePerfMapOnExit`? ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Wed Oct 21 09:13:10 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 21 Oct 2020 09:13:10 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 04:34:44 GMT, Yasumasa Suenaga wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for review comments > > src/hotspot/share/code/codeCache.cpp line 1562: > >> 1560: } >> 1561: >> 1562: void CodeCache::write_perf_map(outputStream* st) { > > Should this code (and changes in header files) be included for Linux only? (`#ifdef LINUX` like the change in diagnosticCommand.cpp) I'm not sure, I didn't want to add too much `#ifdef` mess. The code will compile on other platforms, it just won't be called. Better to add `#ifdef`s around all of it? ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Wed Oct 21 09:13:11 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 21 Oct 2020 09:13:11 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Tue, 20 Oct 2020 11:43:17 GMT, Vladimir Sitnikov wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for review comments > > test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 68: > >> 66: Matcher m = outputPattern.matcher(line); >> 67: >> 68: Assert.assertTrue(m.matches(), "Did not print map file name"); > > Suggestion: > > Assert.assertTrue(m.matches(), "Did not print map file name, line = " + line); Done, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From coleenp at openjdk.java.net Tue Oct 20 12:10:26 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 20 Oct 2020 12:10:26 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: References: <0UtoOZMbgTY-1hGACS1n5swvRCa9za_e3uu-XEVOidM=.85baf76c-e91b-492a-8841-10d9e49e3ec4@github.com> Message-ID: On Tue, 20 Oct 2020 07:17:24 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1525: >> >>> 1523: Thread* current_thread = Thread::current(); >>> 1524: HandleMark hm(current_thread); >>> 1525: JavaThread* java_thread = target->as_Java_thread(); >> >> Contrast with the same three lines at L1390 - we should use the same boilerplate in each `doit`. And ideally refactor >> into some shared code somewhere (future RFE). > > Yes, that would be good. Why don't you just do: JavaThread* java_thread = JavaThread::current(); HandleMark hm(java_thread); JavaThread::current is the same thing as what you have. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Wed Oct 21 10:21:23 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 21 Oct 2020 10:21:23 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v2] In-Reply-To: References: Message-ID: > The following test cases try to provoke VMOutOfMemoryException during object reallocation: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > This is not 100% reliable therefore it should not be treated as test failure if no oom was raised. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Make OOME more reliable and skip test cases if it is not expected because scalar replacement is disabled ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/775/files - new: https://git.openjdk.java.net/jdk/pull/775/files/16f9782d..4196a421 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=00-01 Stats: 37 lines in 1 file changed: 25 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/775/head:pull/775 PR: https://git.openjdk.java.net/jdk/pull/775 From rrich at openjdk.java.net Wed Oct 21 10:24:00 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 21 Oct 2020 10:24:00 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown In-Reply-To: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> References: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> Message-ID: <1Men5jQJjND5dMM9bWdoor-2l4wDRSopfRZT-13nnkg=.bf5b200e-3b7a-4e09-a426-02fc633c9934@github.com> On Tue, 20 Oct 2020 22:45:45 GMT, Chris Plummer wrote: > If the test does not throw OOME, has it actually tested anything in that > case? If an OOME is expected then it has tested object reallocation in frames affected by PopFrame/ForceEarlyReturn. But there are runs where OOME is not expected. I added a new commit which skips the test cases then. > My concern with any test that allows for what is suppose to be an > occasional failure it that it will not detect if something breaks and causes > that failure to happen every time, often rendering the test useless. I can follow that concern. My problem is that I cannot reproduce the failure. Note also that the OOME is successfully generated during object reallocation a couple of times before (search "run args" in attachments to the JBS issue). I'd think the approach to prove the OOME during the PopFrame/ForceEarlyReturn [1] is relatively reliable knowing how smart GCs try to be with avoiding it. I've tried to make it even more reliable with a second commit in this pr. Would that be ok? Maybe you would know a better way? Thanks, Richard. [1] https://github.com/openjdk/jdk/blob/7e2640432bf4fb5115c2ff694c09937234e6d1c5/test/jdk/com/sun/jdi/EATests.java#L1089 ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From rehn at openjdk.java.net Wed Oct 21 13:44:16 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 21 Oct 2020 13:44:16 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v2] In-Reply-To: References: <5R147e7WLawIyLWxjBQUNK22Y19rDsT32HYDCUXep7g=.a2344642-ca05-429e-a733-4ead81eb4f20@github.com> <010C_PcZp7Ol1SpH7__fIb5SPJrbFaQMUa0DN_R2rtM=.49983d69-0901-4081-9043-fbfaef0e4c61@github.com> <-vefsX3p5IkTBZvrIepZdJ-Q1G9HoSDsyVj2M3dkyKc=.03e18d1d-341f-45cc-a25b-c2894ae373e8@github.com> <_akbNkG-trhkT8U9QefeEYexY06Ztv6F2HiFHZF3alI=.d7f4266e-1460-433c-8e20-8dea52d927aa@github.com> Message-ID: On Wed, 21 Oct 2020 08:32:25 GMT, Robbin Ehn wrote: >>> Thanks, I'm exploring what we need to execute the EB inside the handshake. >> >> I want to experiment with object reallocation without referencing a frame. I think a should be possible to reallocate objects given only the corresponding compiled pc. If so, then a handshake/vm operation can fail with the request to reallocate objects at a pc. This can be done concurrently and then the handshake/vm operation can be restarted. > > I pushed the merge. (I manage to pick up bad state in first merge, so I did a second merge to get the fixes for that) > Please have a look. > > Still running test, but there were some interest in this change-set (it seem to fix an unrelated bug also) so I published it. No issues in testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Wed Oct 21 14:19:26 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 21 Oct 2020 14:19:26 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote: >> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >> But we also remove some complicated S/R methods. >> >> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >> >> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >> >> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Fixed merge miss > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Merge fix from Richard > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Removed TraceSuspendDebugBits > - Removed unused method is_ext_suspend_completed_with_lock > - Utilize handshakes instead of is_thread_fully_suspended The change is good. I've only added a few comments (nothing important really). Thanks, also for giving precedence to me ;) src/hotspot/share/prims/jvmtiEnvBase.cpp line 1631: > 1629: _state->set_pending_step_for_popframe(); > 1630: _result = JVMTI_ERROR_NONE; > 1631: } I'd suggest to eliminate jt and use java_thread instead. Also because you're using java_thread in line 1626. The assertion should check if `_state->get_thread() == target` then. src/hotspot/share/prims/jvmtiEnv.cpp line 1808: > 1806: } > 1807: if (java_lang_Class::is_primitive(k_mirror)) { > 1808: return JVMTI_ERROR_NONE; The call of JvmtiSuspendControl::print() seems to be eliminated. Ok for me. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1454: > 1452: _state->set_earlyret_pending(); > 1453: _state->set_earlyret_oop(ret_ob_h()); > 1454: _state->set_earlyret_value(_value, _tos); Good that these updates are done with a handshake now. Maybe I'm missing s.th. but I don't see synchronization in the older version. src/hotspot/share/prims/jvmtiEnvBase.hpp line 310: > 308: GrowableArray *owned_monitors_list); > 309: static jvmtiError check_top_frame(Thread* current_thread, JavaThread* java_thread, > 310: jvalue value, TosState tos, Handle* ret_ob_h); Maybe fix indentation? src/hotspot/share/runtime/deoptimization.cpp line 1771: > 1769: Deoptimization::deoptimize_frame_internal(thread, id, reason); > 1770: } else { > 1771: VM_DeoptimizeFrame deopt(thread, id, reason); I guess VM_DeoptimizeFrame can be replaced with a handshake too now. src/hotspot/share/runtime/thread.cpp line 537: > 535: // cancelled). Returns true if the thread is externally suspended and > 536: // false otherwise. > 537: bool JavaThread::is_ext_suspend_completed() { I'd think `JavaThread::is_ext_suspend_completed` can be removed also (as a separate enhancement). It also duplicates code of the handshake mechanism. Just replace VM_ThreadSuspend with a handshake. ------------- Marked as reviewed by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Wed Oct 21 14:23:26 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 21 Oct 2020 14:23:26 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> References: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> Message-ID: <0yF3nXkvKHHTheoHvF4IQJ9v98AjHl-7R9tSo1qrOec=.367302e8-9414-455d-a601-046cdf5a40c8@github.com> On Wed, 21 Oct 2020 14:06:22 GMT, Richard Reingruber wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Merge fix from Richard >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Removed TraceSuspendDebugBits >> - Removed unused method is_ext_suspend_completed_with_lock >> - Utilize handshakes instead of is_thread_fully_suspended > > src/hotspot/share/runtime/deoptimization.cpp line 1771: > >> 1769: Deoptimization::deoptimize_frame_internal(thread, id, reason); >> 1770: } else { >> 1771: VM_DeoptimizeFrame deopt(thread, id, reason); > > I guess VM_DeoptimizeFrame can be replaced with a handshake too now. Not in this pr of course :) ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From shade at openjdk.java.net Wed Oct 21 17:31:37 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Oct 2020 17:31:37 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v5] In-Reply-To: References: Message-ID: > This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to `Instrumentation`, and let the tools use that fast path today. > > With this patch, JOL is able to be close to `deepSizeOf` implementation from SizeOf JEP. > > Example performance improvements for sizing up a custom linked list: > > Benchmark (size) Mode Cnt Score Error Units > > # Default > LinkedChainBench.linkedChain 1 avgt 5 705.835 ? 8.051 ns/op > LinkedChainBench.linkedChain 10 avgt 5 3148.874 ? 37.856 ns/op > LinkedChainBench.linkedChain 100 avgt 5 28693.256 ? 142.254 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 290161.590 ? 4594.631 ns/op > > # Instrumentation attached, no intrinsics > LinkedChainBench.linkedChain 1 avgt 5 159.659 ? 19.238 ns/op > LinkedChainBench.linkedChain 10 avgt 5 717.659 ? 22.540 ns/op > LinkedChainBench.linkedChain 100 avgt 5 7739.394 ? 111.683 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 80724.238 ? 2887.794 ns/op > > # Instrumentation attached, new intrinsics > LinkedChainBench.linkedChain 1 avgt 5 95.254 ? 0.808 ns/op > LinkedChainBench.linkedChain 10 avgt 5 261.564 ? 8.524 ns/op > LinkedChainBench.linkedChain 100 avgt 5 3367.192 ? 21.128 ns/op > LinkedChainBench.linkedChain 1000 avgt 5 34148.851 ? 373.080 ns/op Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - The new intrinsic-related test - Revert the change to test - Merge branch 'master' into JDK-8253525-sizeof-intrinsics - Add new intrinsics to toBeInvestigated list in CheckGraalIntrinsics.java - 8253525: Implement getInstanceSize/sizeOf intrinsics ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/650/files - new: https://git.openjdk.java.net/jdk/pull/650/files/132f2c50..482c2f24 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=03-04 Stats: 40731 lines in 676 files changed: 27719 ins; 10029 del; 2983 mod Patch: https://git.openjdk.java.net/jdk/pull/650.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/650/head:pull/650 PR: https://git.openjdk.java.net/jdk/pull/650 From shade at openjdk.java.net Wed Oct 21 17:31:37 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Oct 2020 17:31:37 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3] In-Reply-To: References: <0E5sXAWBENg290o8HpKfufH-e69Ue4EfAR074HuNOt4=.3e8af6ad-4aaf-4427-b008-642ca7138f02@github.com> Message-ID: On Tue, 20 Oct 2020 18:12:06 GMT, Vladimir Kozlov wrote: >> It was mistake in 8253191 (I file bug). If you modify existing file (even if you keep only test name the same) you have to preserve original Copyright and add new Copyright line. You don't need create new file. >> We have a lot of cases with 2 or more Copyright lines - it is normal: >> https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/vectorization/TestVectorsNotSavedAtSafepoint.java > > I file 8255067 to restore Copyright line in TestUnsignedByteCompare.java test file. I made sure the new test is in the new file. ------------- PR: https://git.openjdk.java.net/jdk/pull/650 From kvn at openjdk.java.net Wed Oct 21 17:36:22 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 21 Oct 2020 17:36:22 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v5] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 17:31:37 GMT, Aleksey Shipilev wrote: >> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to `Instrumentation`, and let the tools use that fast path today. >> >> With this patch, JOL is able to be close to `deepSizeOf` implementation from SizeOf JEP. >> >> Example performance improvements for sizing up a custom linked list: >> >> Benchmark (size) Mode Cnt Score Error Units >> >> # Default >> LinkedChainBench.linkedChain 1 avgt 5 705.835 ? 8.051 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 3148.874 ? 37.856 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 28693.256 ? 142.254 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 290161.590 ? 4594.631 ns/op >> >> # Instrumentation attached, no intrinsics >> LinkedChainBench.linkedChain 1 avgt 5 159.659 ? 19.238 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 717.659 ? 22.540 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 7739.394 ? 111.683 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 80724.238 ? 2887.794 ns/op >> >> # Instrumentation attached, new intrinsics >> LinkedChainBench.linkedChain 1 avgt 5 95.254 ? 0.808 ns/op >> LinkedChainBench.linkedChain 10 avgt 5 261.564 ? 8.524 ns/op >> LinkedChainBench.linkedChain 100 avgt 5 3367.192 ? 21.128 ns/op >> LinkedChainBench.linkedChain 1000 avgt 5 34148.851 ? 373.080 ns/op > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - The new intrinsic-related test > - Revert the change to test > - Merge branch 'master' into JDK-8253525-sizeof-intrinsics > - Add new intrinsics to toBeInvestigated list in CheckGraalIntrinsics.java > - 8253525: Implement getInstanceSize/sizeOf intrinsics Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/650 From shade at openjdk.java.net Wed Oct 21 17:40:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Oct 2020 17:40:16 GMT Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v5] In-Reply-To: References: Message-ID: <_TFbHUvH8zI29hGvpE3TGGNLGgi7PhP7rfed23up13U=.5a19aaed-cc1e-4d18-997d-f37616323e61@github.com> On Wed, 21 Oct 2020 17:33:27 GMT, Vladimir Kozlov wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - The new intrinsic-related test >> - Revert the change to test >> - Merge branch 'master' into JDK-8253525-sizeof-intrinsics >> - Add new intrinsics to toBeInvestigated list in CheckGraalIntrinsics.java >> - 8253525: Implement getInstanceSize/sizeOf intrinsics > > Good. Thanks for review, @kvn! I would also like a review from someone from serviceability. ------------- PR: https://git.openjdk.java.net/jdk/pull/650 From dcubed at openjdk.java.net Wed Oct 21 17:48:28 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Oct 2020 17:48:28 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote: >> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >> But we also remove some complicated S/R methods. >> >> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >> >> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >> >> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Fixed merge miss > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Merge fix from Richard > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Removed TraceSuspendDebugBits > - Removed unused method is_ext_suspend_completed_with_lock > - Utilize handshakes instead of is_thread_fully_suspended I don't think I have any "must fix" comments here. I'm going to assume that my confusion about why there is code from @reinrich's EscapeBarrier work here is because of the merging of conflicts... src/hotspot/share/prims/jvmtiEnv.cpp line 1646: > 1644: // java_thread - pre-checked > 1645: jvmtiError > 1646: JvmtiEnv::PopFrame(JavaThread* java_thread) { So I'm a bit confused why I'm seeing PopFrame() changes here that are related to @reinrich's EscapeBarrier work. I've seen mention of picking up a patch during this review from @reinrich so may that's why. I don't see anything wrong with the changes, but I am confused why they are here in this review. src/hotspot/share/prims/jvmtiEnv.cpp line 1715: > 1713: } > 1714: > 1715: SetFramePopClosure op(this, state, depth); The new closure is `SetFramePopClosure`, but the function we are in is `NotifyFramePop()` so that seems like a mismatch. Update: Okay, that just a move of existing code so this "mismatch" is pre-existing. src/hotspot/share/prims/jvmtiEnv.cpp line 1718: > 1716: MutexLocker mu(JvmtiThreadState_lock); > 1717: if (java_thread == JavaThread::current()) { > 1718: op.doit(java_thread, true); Please add a comment after the `true` parameter to indicate the name of the doit() function's parameter, e.g., `true /* self */`. src/hotspot/share/prims/jvmtiEnvBase.cpp line 56: > 54: #include "runtime/threadSMR.hpp" > 55: #include "runtime/vframe.hpp" > 56: #include "runtime/vframe.inline.hpp" When you add `foo.inline.hpp` you delete `foo.hpp` because the `foo.inline.hpp` file always includes the `foo.hpp` file. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1311: > 1309: // It is to keep a ret_ob_h handle alive after return to the caller. > 1310: jvmtiError > 1311: JvmtiEnvBase::check_top_frame(Thread* current_thread, JavaThread* java_thread, Again, it is not clear why these changes to `check_top_frame` are here since they appear to be related to @reinrich's work. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1398: > 1396: SetForceEarlyReturn op(state, value, tos); > 1397: if (java_thread == current_thread) { > 1398: op.doit(java_thread, true); Please add a comment after the true parameter to indicate the name of the doit() function's parameter, e.g., `true /* self */`. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1570: > 1568: > 1569: ResourceMark rm(current_thread); > 1570: // Check if there are more than one Java frame in this thread, that the top two frames typo: s/are more/is more/ src/hotspot/share/prims/jvmtiEnvBase.cpp line 1543: > 1541: HandleMark hm(current_thread); > 1542: JavaThread* java_thread = target->as_Java_thread(); > 1543: This would be useful here: `assert(_state->get_thread() == java_thread, "Must be");` src/hotspot/share/prims/jvmtiEnvBase.cpp line 1642: > 1640: > 1641: if (!self) { > 1642: if (!java_thread->is_external_suspend()) { You could join these two if-statements with `&&` and have one less indenting level... src/hotspot/share/prims/jvmtiEnvBase.cpp line 1661: > 1659: assert(vf->frame_pointer() != NULL, "frame pointer mustn't be NULL"); > 1660: if (java_thread->is_exiting() || java_thread->threadObj() == NULL) { > 1661: return; What's the `_result` value if this `return` executes? src/hotspot/share/prims/jvmtiEnvBase.hpp line 361: > 359: _tos(tos) {} > 360: void do_thread(Thread *target) { > 361: doit(target, false); Please add a comment after the true parameter to indicate the name of the doit() function's parameter, e.g., `false /* self */`. src/hotspot/share/prims/jvmtiEnvBase.hpp line 395: > 393: _depth(depth) {} > 394: void do_thread(Thread *target) { > 395: doit(target, false); Please add a comment after the true parameter to indicate the name of the doit() function's parameter, e.g., `false /* self */`. src/hotspot/share/runtime/deoptimization.cpp line 1755: > 1753: thread->is_handshake_safe_for(Thread::current()) || > 1754: SafepointSynchronize::is_at_safepoint(), > 1755: "can only deoptimize other thread at a safepoint"); Should that now be: `safepoint/handshake`?? src/hotspot/share/runtime/thread.cpp line 567: > 565: // > 566: // _thread_in_native -> _thread_in_native_trans -> _thread_blocked > 567: // This code should not be needed with the much simpler suspension mechanism. (My agreement may come back to bite me if we have to change a suspend/resume bug in the near future. :-) ) src/hotspot/share/runtime/thread.cpp line 698: > 696: RememberProcessedThread rpt(this); > 697: oops_do_no_frames(f, cf); > 698: oops_do_frames(f, cf); In the comment above: // ... If we were // called by wait_for_ext_suspend_completion(), then it // will be doing the retries so we don't have to. `wait_for_ext_suspend_completion()` has been deleted so the comment needs work. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/729 From dcubed at openjdk.java.net Wed Oct 21 17:48:31 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Oct 2020 17:48:31 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> References: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> Message-ID: On Wed, 21 Oct 2020 13:46:14 GMT, Richard Reingruber wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Merge fix from Richard >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Removed TraceSuspendDebugBits >> - Removed unused method is_ext_suspend_completed_with_lock >> - Utilize handshakes instead of is_thread_fully_suspended > > src/hotspot/share/prims/jvmtiEnv.cpp line 1808: > >> 1806: } >> 1807: if (java_lang_Class::is_primitive(k_mirror)) { >> 1808: return JVMTI_ERROR_NONE; > > The call of JvmtiSuspendControl::print() seems to be eliminated. Ok for me. It's not clear to me why the `JvmtiSuspendControl::print()` is being eliminated. Please explain. The `TraceJVMTICalls` support is so that someone can diagnose what JVM/TI calls are being made, including context in some cases, so it seems wrong to delete this call. > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1454: > >> 1452: _state->set_earlyret_pending(); >> 1453: _state->set_earlyret_oop(ret_ob_h()); >> 1454: _state->set_earlyret_value(_value, _tos); > > Good that these updates are done with a handshake now. Maybe I'm missing s.th. but I don't see synchronization in the older version. Agreed. @sspitsyn - This makes me wonder if the lack of synchronization is the cause of some instability in the JVM/TI ForceEarlyReturn() testing. Update: The old code only made the updates if the thread was fully suspended so you won't have a race between the requesting thread and the target thread in that case. > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1631: > >> 1629: _state->set_pending_step_for_popframe(); >> 1630: _result = JVMTI_ERROR_NONE; >> 1631: } > > I'd suggest to eliminate jt and use java_thread instead. Also because you're using java_thread in line 1626. The assertion should check if `_state->get_thread() == target` then. Especially if an assert() is added above on L1543. > src/hotspot/share/runtime/thread.cpp line 537: > >> 535: // cancelled). Returns true if the thread is externally suspended and >> 536: // false otherwise. >> 537: bool JavaThread::is_ext_suspend_completed() { > > I'd think `JavaThread::is_ext_suspend_completed` can be removed also (as a separate enhancement). It also duplicates code of the handshake mechanism. Just replace VM_ThreadSuspend with a handshake. `is_ext_suspend_completed()` includes code that detects that a thread that is in `_thread_in_native_trans` and does not yet have a walkable stack has not completed suspension and we will do some retries in this function until the target thread gets stable. We have to make sure that the handshake mechanism has a similar stability guarantee or a stack walker may fail intermittently. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From cjplummer at openjdk.java.net Wed Oct 21 18:00:19 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 21 Oct 2020 18:00:19 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 09:08:06 GMT, Nick Gasson wrote: >> src/hotspot/share/code/codeCache.cpp line 1562: >> >>> 1560: } >>> 1561: >>> 1562: void CodeCache::write_perf_map(outputStream* st) { >> >> Should this code (and changes in header files) be included for Linux only? (`#ifdef LINUX` like the change in diagnosticCommand.cpp) > > I'm not sure, I didn't want to add too much `#ifdef` mess. The code will compile on other platforms, it just won't be called. Better to add `#ifdef`s around all of it? Any reason not to have this dcmd supported on all platforms even though the output is really targeted for use with the perf tool on linux? Would a user ever have any other use for the output other than with the perf tool on linux? ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From cjplummer at openjdk.java.net Wed Oct 21 18:06:22 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 21 Oct 2020 18:06:22 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 09:13:08 GMT, Nick Gasson wrote: >> When using the Linux "perf" tool to do system profiling, symbol names of >> running Java methods cannot be decoded, resulting in unhelpful output >> such as: >> >> 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 >> >> Perf can read a simple text file format describing the mapping between >> address ranges and symbol names for a particular process [1]. >> >> It's possible to generate this already for Java processes using a JVMTI >> plugin such as perf-map-agent [2]. However this requires compiling >> third-party code and then loading the agent into your Java process. It >> would be more convenient if Hotspot could write this file directly using >> a diagnostic command. The information required is almost identical to >> that of the existing Compiler.codelist command. >> >> This patch adds a Compiler.perfmap diagnostic command on Linux only. To >> use, first run "jcmd Compiler.perfmap" and then "perf top" or >> "perf record" and the report should show decoded Java symbol names for >> that process. >> >> As this just writes a snapshot of the code cache when the command is >> run, it will become stale if methods are compiled later or unloaded. >> However this shouldn't be a big problem in practice if the map file is >> generated after the application has warmed up. >> >> [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt >> [2] https://github.com/jvm-profiling-tools/perf-map-agent > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Update for review comments src/hotspot/share/code/codeCache.cpp line 1582: > 1580: cb->is_compiled() ? cb->as_compiled_method()->method()->external_name() > 1581: : cb->name(); > 1582: fs.print_cr(INTPTR_FORMAT " " INTPTR_FORMAT " %s", Indentation isn't right. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From cjplummer at openjdk.java.net Wed Oct 21 20:07:09 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 21 Oct 2020 20:07:09 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown In-Reply-To: <1Men5jQJjND5dMM9bWdoor-2l4wDRSopfRZT-13nnkg=.bf5b200e-3b7a-4e09-a426-02fc633c9934@github.com> References: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> <1Men5jQJjND5dMM9bWdoor-2l4wDRSopfRZT-13nnkg=.bf5b200e-3b7a-4e09-a426-02fc633c9934@github.com> Message-ID: On Wed, 21 Oct 2020 10:21:05 GMT, Richard Reingruber wrote: >> If the test does not throw OOME, has it actually tested anything in that case? My concern with any test that allows for what is suppose to be an occasional failure it that it will not detect if something breaks and causes that failure to happen every time, often rendering the test useless. > >> If the test does not throw OOME, has it actually tested anything in that >> case? > > If an OOME is expected then it has tested object reallocation in frames affected > by PopFrame/ForceEarlyReturn. > > But there are runs where OOME is not expected. I added a new commit which skips > the test cases then. > >> My concern with any test that allows for what is suppose to be an >> occasional failure it that it will not detect if something breaks and causes >> that failure to happen every time, often rendering the test useless. > > I can follow that concern. My problem is that I cannot reproduce the > failure. Note also that the OOME is successfully generated during object > reallocation a couple of times before (search "run args" in attachments > to the JBS issue). > > I'd think the approach to prove the OOME during the PopFrame/ForceEarlyReturn > [1] is relatively reliable knowing how smart GCs try to be with avoiding it. > > I've tried to make it even more reliable with a second commit in this pr. > > Would that be ok? Maybe you would know a better way? > > Thanks, Richard. > > [1] https://github.com/openjdk/jdk/blob/7e2640432bf4fb5115c2ff694c09937234e6d1c5/test/jdk/com/sun/jdi/EATests.java#L1089 I'm not following how the introduction of LinkedListOfLongArrays is making the OOME even more reliable. Can you please elaborate? Is consumeAllMemory() being called from a different thread than the one doing the forceEarlyReturn? If so, you might be running into an issue because the tlab still has available memory to allocate. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From cjplummer at openjdk.java.net Wed Oct 21 20:15:14 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 21 Oct 2020 20:15:14 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 00:21:14 GMT, Igor Ignatyev wrote: >> I don't follow. You seem to have added an extra 4 (after having already indented 4 extra spaces) simply because it is an array initialization. Why is the indentation any different than it would be for something like a "for" loop block. The body of the block is indented 4 spaces more than the "for" statement. For the static initialization the body of that "static" block should be indented 4 more than the "static" statement. I don't see anything in the style guide that would indicate otherwise. > > oh, sorry, it appears I was trying to explain the new code while looking at the old one... > > full disclaimer, which I thought was obvious, the vast majority of the changes here aren't done by me, they are done by auto-formatter, or more precisely by IntelliJ IDEA's formatter. IDEA doesn't consider array initialization as a new block, and what's actually at play here is an indent for statement continuation (which is 2x of regular indent). Do you plan on leaving these indented 8 instead of 4 because that's what IDEA defaults to? Other editors, like emacs, will want to indent them 4, and will do so often do so automatically just by editing the line, depending on whether you type any character that forces reformatting of indentation. Do we have coding guidelines that say to indent them 8? ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From sjohanss at openjdk.java.net Wed Oct 21 20:51:16 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 21 Oct 2020 20:51:16 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v4] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 13:09:34 GMT, Lin Zang wrote: >> - Parallel heap iteration support for PSS >> - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 > > Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Hi Lin, A nice improvement over the last version. I still have some comments though. src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 543: > 541: > 542: void ParallelScavengeHeap::object_iterate_parallel(ObjectClosure* cl, > 543: uint worker_id, `worker_id` is never used, please remove. src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 562: > 560: HeapBlockClaimer::HeapBlockClaimer(uint n_workers) : > 561: _n_workers(n_workers), _n_blocks(0), _claims(NULL) { > 562: assert(n_workers > 0, "Need at least one worker."); Unless I'm missing something the only use of `_n_workers` is the assert here and I think it's better to just skip it. src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 565: > 563: size_t old_gen_used = ParallelScavengeHeap::heap()->old_gen()->used_in_bytes(); > 564: size_t block_size = ParallelScavengeHeap::heap()->old_gen()->iterate_block_size(); > 565: uint n_blocks_in_old = old_gen_used / block_size + 1; Instead of doing this calculation here, what do you think about making `iterate_block_size()` a constant in `PSOldGen` and instead adding a function that returns the number of blocks available, something like: `iterable_blocks()` src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 591: > 589: } > 590: next_index = Atomic::load(&_unclaimed_index); > 591: } I think this can be simplified a bit. If you use Atomic::fetch_and_add() for the claiming, you only need `_unclaimed_index` and can get rid of `_claims`. I think you might want to rename it to `_claimed_index` or something. It could look something like this: Suggestion: assert(block_index != NULL, "Invalid index pointer"); *block_index = Atomic::fetch_and_add(&_claimed_index, 1); if (*block_index >= _n_blocks) { return false; } return true; src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 604: > 602: _thread_num(thread_num), > 603: _heap(ParallelScavengeHeap::heap()), > 604: _claimer(thread_num == 0 ? ParallelScavengeHeap::heap()->workers().active_workers() : thread_num) {} As mentioned, the `_claimer` don't need the number of threads so it can be removed from here as well. src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 297: > 295: // The HeapBlockClaimer is used during parallel iteration over heap, > 296: // allowing workers to claim heap blocks, gaining exclusive rights to these blocks. > 297: // The eden, survivor spaces are treated as single blocks as it is hard to divide Suggestion: // The eden and survivor spaces are treated as single blocks as it is hard to divide src/hotspot/share/gc/parallel/psOldGen.cpp line 200: > 198: // iterate objects in block. > 199: HeapWord* end = MIN2(top, begin + _iterate_block_size); > 200: // There can be no object between begin and end. I would change this to something like: "Only iterate if there are objects between begin and end. src/hotspot/share/gc/parallel/psOldGen.hpp line 56: > 54: > 55: // Block size for parallel iteration > 56: const size_t _iterate_block_size; Turn into constant. ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From sjohanss at openjdk.java.net Wed Oct 21 20:59:16 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 21 Oct 2020 20:59:16 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v4] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 13:09:34 GMT, Lin Zang wrote: >> - Parallel heap iteration support for PSS >> - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 > > Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 318: > 316: static const uint eden_index = 0; > 317: static const uint survivor_index = 1; > 318: static const uint num_inseparable_spaces = 2; One more comment. These should be CamelCase, and I have an idea to get rid of `num_inseparable_spaces`. If we make `_claimed_index` an integral type we could define `EdenIndex = -2` and `SurvivorIndex = -1`. If we then initialize `_claimed_index = EdenIndex` the old gen indices will be correct without needing a decrease. ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From sspitsyn at openjdk.java.net Wed Oct 21 21:04:15 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 21 Oct 2020 21:04:15 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 17:57:46 GMT, Chris Plummer wrote: >> I'm not sure, I didn't want to add too much `#ifdef` mess. The code will compile on other platforms, it just won't be called. Better to add `#ifdef`s around all of it? > > Any reason not to have this dcmd supported on all platforms even though the output is really targeted for use with the perf tool on linux? Would a user ever have any other use for the output other than with the perf tool on linux? +#ifdef LINUX + DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl(full_export, true, false)); +#endif // LINUX If this PR is for Linux only then I wonder if all changes have to be ifdef'ed the same or similar way. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From sspitsyn at openjdk.java.net Wed Oct 21 21:04:16 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 21 Oct 2020 21:04:16 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 21:00:01 GMT, Serguei Spitsyn wrote: >> Any reason not to have this dcmd supported on all platforms even though the output is really targeted for use with the perf tool on linux? Would a user ever have any other use for the output other than with the perf tool on linux? > > +#ifdef LINUX > + DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl(full_export, true, false)); > +#endif // LINUX > > If this PR is for Linux only then I wonder if all changes have to be ifdef'ed the same or similar way. Sorry, I've overlooked that @YaSuenag posted similar comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From rrich at openjdk.java.net Wed Oct 21 21:12:21 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 21 Oct 2020 21:12:21 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 17:45:20 GMT, Daniel D. Daugherty wrote: > I'm going to assume that my confusion about why there > is code from @reinrich's EscapeBarrier work here is > because of the merging of conflicts... That's correct. #119 got integrated and this pr needs to resolve a few locations because it moves code that has EscapeBarriers into handshakes. EBs cannot be executed in a handshake as they can safepoint doing heap allocations so they are moved before the handshake. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From iignatyev at openjdk.java.net Wed Oct 21 21:13:11 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 21 Oct 2020 21:13:11 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 20:12:51 GMT, Chris Plummer wrote: > Do we have coding guidelines that say to indent them 8? old "official" guidelines don't tell much about it, @aioobe's guidelines don't special-case array initiation, so it is covered by: > A continuation line should be indented in one of the following four ways > Variant 1: With 8 extra spaces relative to the indentation of the previous line. > Variant 2: With 8 extra spaces relative to the starting column of the wrapped expression. > Variant 3: Aligned with previous sibling expression (as long as it is clear that it?s a continuation line) > Variant 4: Aligned with previous method call in a chained expression. which will suggest that 8 is the right indent here. google's code-style says that "array initializer may _optionally_ be formatted as if it were a "block-like construct.", which would mean 4, but note "may" and "_optionally_". personally I'd prefer consistency here, but if you think it will make the lives of emacs-lovers miserable, although I'm sure you can configure emacs to treat array-init as line continuation, and not as a block, I can revert that. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From dcubed at openjdk.java.net Wed Oct 21 21:16:19 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Oct 2020 21:16:19 GMT Subject: RFR: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC Message-ID: Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. ------------- Commit messages: - Must learn to not type too fast... - Only the first test case is failing. - 8255200: ProblemList com/sun/jdi/EATests.java for ZGC Changes: https://git.openjdk.java.net/jdk/pull/787/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=787&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255200 Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/787.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/787/head:pull/787 PR: https://git.openjdk.java.net/jdk/pull/787 From kvn at openjdk.java.net Wed Oct 21 21:27:13 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 21 Oct 2020 21:27:13 GMT Subject: RFR: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 21:04:55 GMT, Daniel D. Daugherty wrote: > Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/787 From dcubed at openjdk.java.net Wed Oct 21 21:34:13 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Oct 2020 21:34:13 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown In-Reply-To: References: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> <1Men5jQJjND5dMM9bWdoor-2l4wDRSopfRZT-13nnkg=.bf5b200e-3b7a-4e09-a426-02fc633c9934@github.com> Message-ID: On Wed, 21 Oct 2020 20:04:54 GMT, Chris Plummer wrote: >>> If the test does not throw OOME, has it actually tested anything in that >>> case? >> >> If an OOME is expected then it has tested object reallocation in frames affected >> by PopFrame/ForceEarlyReturn. >> >> But there are runs where OOME is not expected. I added a new commit which skips >> the test cases then. >> >>> My concern with any test that allows for what is suppose to be an >>> occasional failure it that it will not detect if something breaks and causes >>> that failure to happen every time, often rendering the test useless. >> >> I can follow that concern. My problem is that I cannot reproduce the >> failure. Note also that the OOME is successfully generated during object >> reallocation a couple of times before (search "run args" in attachments >> to the JBS issue). >> >> I'd think the approach to prove the OOME during the PopFrame/ForceEarlyReturn >> [1] is relatively reliable knowing how smart GCs try to be with avoiding it. >> >> I've tried to make it even more reliable with a second commit in this pr. >> >> Would that be ok? Maybe you would know a better way? >> >> Thanks, Richard. >> >> [1] https://github.com/openjdk/jdk/blob/7e2640432bf4fb5115c2ff694c09937234e6d1c5/test/jdk/com/sun/jdi/EATests.java#L1089 > > I'm not following how the introduction of LinkedListOfLongArrays is making the OOME even more reliable. Can you please elaborate? > > Is consumeAllMemory() being called from a different thread than the one doing the forceEarlyReturn? If so, you might be running into an issue because the tlab still has available memory to allocate. @reinrich - when your reviewers have agreed to a fix, please remove the ProblemListing that I did via: https://github.com/openjdk/jdk/pull/787 ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From iignatyev at openjdk.java.net Wed Oct 21 21:37:15 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 21 Oct 2020 21:37:15 GMT Subject: RFR: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC In-Reply-To: References: Message-ID: <0vi5PXjYPOdQy5wrB72cqJwlGm2BGD7kUGB6s6G1z8Y=.779a3b02-e755-4183-90ea-1ebf836c20ff@github.com> On Wed, 21 Oct 2020 21:04:55 GMT, Daniel D. Daugherty wrote: > Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/787 From dholmes at openjdk.java.net Wed Oct 21 21:37:15 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Oct 2020 21:37:15 GMT Subject: RFR: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC In-Reply-To: References: Message-ID: <5aMRZ_X8Gdo6keu6uADnX4IGe5m5ySl-T6JO5elZeGE=.a1d8e1bb-d616-421b-8ddf-ed04082aa034@github.com> On Wed, 21 Oct 2020 21:04:55 GMT, Daniel D. Daugherty wrote: > Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/787 From dcubed at openjdk.java.net Wed Oct 21 21:37:17 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Oct 2020 21:37:17 GMT Subject: Integrated: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 21:04:55 GMT, Daniel D. Daugherty wrote: > Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. This pull request has now been integrated. Changeset: 34450311 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/34450311 Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod 8255200: ProblemList com/sun/jdi/EATests.java for ZGC Reviewed-by: kvn, iignatyev, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/787 From dcubed at openjdk.java.net Wed Oct 21 21:37:15 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Oct 2020 21:37:15 GMT Subject: RFR: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC In-Reply-To: <5aMRZ_X8Gdo6keu6uADnX4IGe5m5ySl-T6JO5elZeGE=.a1d8e1bb-d616-421b-8ddf-ed04082aa034@github.com> References: <5aMRZ_X8Gdo6keu6uADnX4IGe5m5ySl-T6JO5elZeGE=.a1d8e1bb-d616-421b-8ddf-ed04082aa034@github.com> Message-ID: On Wed, 21 Oct 2020 21:28:45 GMT, David Holmes wrote: >> Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. > > Looks good. > > Thanks, > David Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/787 From rrich at openjdk.java.net Wed Oct 21 21:41:13 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 21 Oct 2020 21:41:13 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown In-Reply-To: References: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> <1Men5jQJjND5dMM9bWdoor-2l4wDRSopfRZT-13nnkg=.bf5b200e-3b7a-4e09-a426-02fc633c9934@github.com> Message-ID: On Wed, 21 Oct 2020 20:04:54 GMT, Chris Plummer wrote: > > > I'm not following how the introduction of LinkedListOfLongArrays is making the OOME even more reliable. Can you please elaborate? The new LinkedListOfLongArrays is created by renaming LinkedList to LinkedListOfLongArrays. The new LinkedList is a list node without payload, so it is smaller than a LinkedListOfLongArrays node. I try to fill the last free blocks with these. But yeah, this won't make that much of a difference. > Is consumeAllMemory() being called from a different thread than the one doing > the forceEarlyReturn? If so, you might be running into an issue because the > tlab still has available memory to allocate. Yes, the threads are different (well observed :)). As far as I know tlabs are retired before gc. I'd expect that they are allocated lazily. So the jdwp agent thread that does the forceEarlyReturn should not have a tlab at hand. Certainly these are just assumptions. It would be easy to implement the gc interface(*) with different heuristics. (*) Roman Kennke and Aleksey Shipilev demo'ed implementing the gc interface in a FOSDEM talk. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From rrich at openjdk.java.net Wed Oct 21 21:44:14 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 21 Oct 2020 21:44:14 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown In-Reply-To: References: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> <1Men5jQJjND5dMM9bWdoor-2l4wDRSopfRZT-13nnkg=.bf5b200e-3b7a-4e09-a426-02fc633c9934@github.com> Message-ID: <0KoVjvXFG39a_i3-kMYUPU1oznr9LAXJbEceqG3h4Bo=.4e590ae2-cafb-4bc4-95a3-97f2a8ceefc0@github.com> On Wed, 21 Oct 2020 21:38:08 GMT, Richard Reingruber wrote: >> I'm not following how the introduction of LinkedListOfLongArrays is making the OOME even more reliable. Can you please elaborate? >> >> Is consumeAllMemory() being called from a different thread than the one doing the forceEarlyReturn? If so, you might be running into an issue because the tlab still has available memory to allocate. > >> >> >> I'm not following how the introduction of LinkedListOfLongArrays is making the OOME even more reliable. Can you please elaborate? > > The new LinkedListOfLongArrays is created by renaming LinkedList to > LinkedListOfLongArrays. The new LinkedList is a list node without payload, so it > is smaller than a LinkedListOfLongArrays node. I try to fill the last free > blocks with these. But yeah, this won't make that much of a difference. > >> Is consumeAllMemory() being called from a different thread than the one doing >> the forceEarlyReturn? If so, you might be running into an issue because the >> tlab still has available memory to allocate. > > Yes, the threads are different (well observed :)). As far as I know tlabs are > retired before gc. I'd expect that they are allocated lazily. So the jdwp agent > thread that does the forceEarlyReturn should not have a tlab at hand. Certainly > these are just assumptions. It would be easy to implement the gc interface(*) > with different heuristics. > > (*) Roman Kennke and Aleksey Shipilev demo'ed implementing the gc interface in a > FOSDEM talk. > > > @reinrich - when your reviewers have agreed to a fix, please remove the > ProblemListing that I did via: #787 I will. Thanks for doing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From cjplummer at openjdk.java.net Wed Oct 21 21:56:11 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 21 Oct 2020 21:56:11 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 21:10:54 GMT, Igor Ignatyev wrote: >> Do you plan on leaving these indented 8 instead of 4 because that's what IDEA defaults to? Other editors, like emacs, will want to indent them 4, and will do so often do so automatically just by editing the line, depending on whether you type any character that forces reformatting of indentation. >> >> Do we have coding guidelines that say to indent them 8? > >> Do we have coding guidelines that say to indent them 8? > > old "official" guidelines don't tell much about it, @aioobe's guidelines don't special-case array initiation, so it is covered by: >> A continuation line should be indented in one of the following four ways >> Variant 1: With 8 extra spaces relative to the indentation of the previous line. >> Variant 2: With 8 extra spaces relative to the starting column of the wrapped expression. >> Variant 3: Aligned with previous sibling expression (as long as it is clear that it?s a continuation line) >> Variant 4: Aligned with previous method call in a chained expression. > > which will suggest that 8 is the right indent here. > > google's code-style says that "array initializer may _optionally_ be formatted as if it were a "block-like construct.", which would mean 4, but note "may" and "_optionally_". personally I'd prefer consistency here, but if you think it will make the lives of emacs-lovers miserable, although I'm sure you can configure emacs to treat array-init as line continuation, and not as a block, I can revert that. I don't consider this to be a continuation line. It just looks too much like a statement block. My other concern is too much seemingly arbitrary reformatting. I really don't like the idea of reformatting an entire file based on some formatter's notion of what is best or correct, leading to unnecessary reformatting like this one. It muddles the history. The exception would be for a file that is hopelessly formatted incorrectly, like using 2-char indentation instead of 4 in java, or 4 char instead of 2 in C. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From dholmes at openjdk.java.net Wed Oct 21 22:50:14 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Oct 2020 22:50:14 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote: >> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >> But we also remove some complicated S/R methods. >> >> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >> >> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >> >> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Fixed merge miss > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Merge fix from Richard > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Removed TraceSuspendDebugBits > - Removed unused method is_ext_suspend_completed_with_lock > - Utilize handshakes instead of is_thread_fully_suspended Incremental updates seem fine to me. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/729 From dholmes at openjdk.java.net Wed Oct 21 23:01:15 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Oct 2020 23:01:15 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> Message-ID: On Wed, 21 Oct 2020 17:12:43 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1631: >> >>> 1629: _state->set_pending_step_for_popframe(); >>> 1630: _result = JVMTI_ERROR_NONE; >>> 1631: } >> >> I'd suggest to eliminate jt and use java_thread instead. Also because you're using java_thread in line 1626. The assertion should check if `_state->get_thread() == target` then. > > Especially if an assert() is added above on L1543. Agreed - this code has become confused about what thread variables are present and their relationship. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From dholmes at openjdk.java.net Wed Oct 21 23:01:17 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Oct 2020 23:01:17 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 17:15:01 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Merge fix from Richard >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Removed TraceSuspendDebugBits >> - Removed unused method is_ext_suspend_completed_with_lock >> - Utilize handshakes instead of is_thread_fully_suspended > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1661: > >> 1659: assert(vf->frame_pointer() != NULL, "frame pointer mustn't be NULL"); >> 1660: if (java_thread->is_exiting() || java_thread->threadObj() == NULL) { >> 1661: return; > > What's the `_result` value if this `return` executes? The default "not alive" value. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From amenkov at openjdk.java.net Wed Oct 21 23:46:11 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 21 Oct 2020 23:46:11 GMT Subject: Integrated: 6606767: resexhausted00[34] fail assert(!thread->owns_locks(), "must release all locks when leaving VM") In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 22:25:34 GMT, Alex Menkov wrote: > Please review the fix for JDK-6606767. > The original issue is not reproducible. > The fix: > - resexhausted003 and resexhausted004 are un-problemlisted > - resexhausted004 is problemlisted on linux due JDK-8253916 (resexhausted004 executes resexhausted001/resexhausted002/resexhausted003 randomly, and resexhausted001 fails on linux) > - resexhausted003 is updated to throw SkippedException if OOME is not thrown; > - resexhausted004 is updated to catch SkippedException from resexhausted001..003, also logic is slightly simplified This pull request has now been integrated. Changeset: b9186beb Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/b9186beb Stats: 21 lines in 3 files changed: 9 ins; 7 del; 5 mod 6606767: resexhausted00[34] fail assert(!thread->owns_locks(), "must release all locks when leaving VM") Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/671 From amenkov at openjdk.java.net Thu Oct 22 00:07:21 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 22 Oct 2020 00:07:21 GMT Subject: RFR: 8252117: com/sun/jdi/BadHandshakeTest.java failed with "ConnectException: Connection refused: connect" Message-ID: Please review the fix for BadHandshakeTest. Summary: The test verifies that bad (testcase1) or incomplete (testcase2) handshake does not cause debuggee termination. To check this it tries to attach to the debuggee again (connect in testcase2 is also verification for testcase1) The fix adds reply logic to the last attach (similar to retry logic in testcase2) ------------- Commit messages: - 8252117: com/sun/jdi/BadHandshakeTest.java failed with "ConnectException: Connection refused: connect" Changes: https://git.openjdk.java.net/jdk/pull/789/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=789&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252117 Stats: 45 lines in 1 file changed: 28 ins; 5 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/789.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/789/head:pull/789 PR: https://git.openjdk.java.net/jdk/pull/789 From ysuenaga at openjdk.java.net Thu Oct 22 01:27:14 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 22 Oct 2020 01:27:14 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 09:09:49 GMT, Nick Gasson wrote: > Yes that sounds like a good idea. Add a (diagnostic?) option `-XX:+WritePerfMapOnExit`? I think we should use this option carefully because nmethod might be unloaded. So we should use this with `-XX:-UseCodeCacheFlushing`. BTW we can use `Compiler.codelist` dcmd for this purpose now. If you implement `WritePerfMapOnExit`, we should consider code cache flushing and should use `Compiler.codelist` in some case. I've published perfmap generator from `Compiler.codelist` https://github.com/YaSuenag/saperf ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ysuenaga at openjdk.java.net Thu Oct 22 02:09:14 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 22 Oct 2020 02:09:14 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 09:13:08 GMT, Nick Gasson wrote: >> When using the Linux "perf" tool to do system profiling, symbol names of >> running Java methods cannot be decoded, resulting in unhelpful output >> such as: >> >> 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 >> >> Perf can read a simple text file format describing the mapping between >> address ranges and symbol names for a particular process [1]. >> >> It's possible to generate this already for Java processes using a JVMTI >> plugin such as perf-map-agent [2]. However this requires compiling >> third-party code and then loading the agent into your Java process. It >> would be more convenient if Hotspot could write this file directly using >> a diagnostic command. The information required is almost identical to >> that of the existing Compiler.codelist command. >> >> This patch adds a Compiler.perfmap diagnostic command on Linux only. To >> use, first run "jcmd Compiler.perfmap" and then "perf top" or >> "perf record" and the report should show decoded Java symbol names for >> that process. >> >> As this just writes a snapshot of the code cache when the command is >> run, it will become stale if methods are compiled later or unloaded. >> However this shouldn't be a big problem in practice if the map file is >> generated after the application has warmed up. >> >> [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt >> [2] https://github.com/jvm-profiling-tools/perf-map-agent > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Update for review comments src/hotspot/share/code/codeCache.cpp line 1571: > 1569: if (!fs.is_open()) { > 1570: log_warning(codecache)("Failed to create %s for perf map", fname); > 1571: st->print_cr("Failed to create %s", fname); `st->print_cr()` is still needed? and also I've intended to replace all `print_cr()` to UL (L1587) ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From vromero at openjdk.java.net Thu Oct 22 02:09:12 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 22 Oct 2020 02:09:12 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Thu, 22 Oct 2020 01:24:20 GMT, Yasumasa Suenaga wrote: >>> >>> Because it seems that for the short jobs, we would like to just do "perf record java -XX:+WhatEver", followed by "perf report", without requiring user to invoke the diagnostic command while JVM is still running? >> >> Yes that sounds like a good idea. Add a (diagnostic?) option `-XX:+WritePerfMapOnExit`? > >> Yes that sounds like a good idea. Add a (diagnostic?) option `-XX:+WritePerfMapOnExit`? > > I think we should use this option carefully because nmethod might be unloaded. So we should use this with `-XX:-UseCodeCacheFlushing`. > > BTW we can use `Compiler.codelist` dcmd for this purpose now. If you implement `WritePerfMapOnExit`, we should consider code cache flushing and should use `Compiler.codelist` in some case. I've published perfmap generator from `Compiler.codelist` https://github.com/YaSuenag/saperf \label remove compiler ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From stuefe at openjdk.java.net Thu Oct 22 05:03:15 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 22 Oct 2020 05:03:15 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 09:13:08 GMT, Nick Gasson wrote: >> When using the Linux "perf" tool to do system profiling, symbol names of >> running Java methods cannot be decoded, resulting in unhelpful output >> such as: >> >> 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 >> >> Perf can read a simple text file format describing the mapping between >> address ranges and symbol names for a particular process [1]. >> >> It's possible to generate this already for Java processes using a JVMTI >> plugin such as perf-map-agent [2]. However this requires compiling >> third-party code and then loading the agent into your Java process. It >> would be more convenient if Hotspot could write this file directly using >> a diagnostic command. The information required is almost identical to >> that of the existing Compiler.codelist command. >> >> This patch adds a Compiler.perfmap diagnostic command on Linux only. To >> use, first run "jcmd Compiler.perfmap" and then "perf top" or >> "perf record" and the report should show decoded Java symbol names for >> that process. >> >> As this just writes a snapshot of the code cache when the command is >> run, it will become stale if methods are compiled later or unloaded. >> However this shouldn't be a big problem in practice if the map file is >> generated after the application has warmed up. >> >> [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt >> [2] https://github.com/jvm-profiling-tools/perf-map-agent > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Update for review comments Hi Nick, this is a very useful idea! I missed this in the past. Some remarks. I'll try to keep bikeshedding to a minimum since you already have enough input. Mostly ergonomics. 1) Like Alexey, I would really wish for an print-at-exit switch. The common naming seems to be xxxAtExit (so not, OnExit). "PrintXxx" seems to be printing stuff out to tty, "DumpXxxx" for writing separate files (e.g. CDS map). So I would name it DumpPerfMapAtExit. 2) Dumping to /tmp is unexpected for me, I would prefer if the default were dumping to the current directory. That seems to be the default for other files too (cds map, hs-err file etc). 3) Not necessary but nice would be a an option to specify location of the dump file. 4) I think it would be nice to have these switches always available, so real product switches. Which would require you to write up a small CSR but I still think it would make sense. Cheers, Thomas src/hotspot/share/code/codeCache.hpp line 194: > 192: static void print_summary(outputStream* st, bool detailed = true); // Prints a summary of the code cache usage > 193: static void log_state(outputStream* st); > 194: static void write_perf_map(outputStream* st); Seems weird for this function to have an outputStream parameter only to write the dump to an unrelated file and ignore the stream for everything but the final message. I would either pass in the file name as an option - preferably configurable - and write the last message out here; or just write the whole perf dump to the outputstream itself, piping it to jcmd and let the caller do what he wants with it (e.g. just redirecting). The latter is what most commands do. Not sure how large the perf dump gets though, may be impractical. src/hotspot/share/code/codeCache.cpp line 1562: > 1560: } > 1561: > 1562: void CodeCache::write_perf_map(outputStream* st) { Could this whole function possibly live inside os/linux in an own file? Or would that expose too many code heap internals? ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From cjplummer at openjdk.java.net Thu Oct 22 05:09:14 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 22 Oct 2020 05:09:14 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown In-Reply-To: References: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> <1Men5jQJjND5dMM9bWdoor-2l4wDRSopfRZT-13nnkg=.bf5b200e-3b7a-4e09-a426-02fc633c9934@github.com> Message-ID: <52rCqsE35JX4M9CR4wco9TNmKArHNlZDPG4hjEKr7FE=.91280ec9-2d2f-48a4-a280-13fe54933e02@github.com> On Wed, 21 Oct 2020 21:38:08 GMT, Richard Reingruber wrote: > The new LinkedListOfLongArrays is created by renaming LinkedList to > LinkedListOfLongArrays. The new LinkedList is a list node without payload, so it > is smaller than a LinkedListOfLongArrays node. I try to fill the last free > blocks with these. But yeah, this won't make that much of a difference. Ok. However, since you can't reproduce the initial problem it's hard to say if this will fix it. You would need to remove it from the problem list with this PR and see what happens. Earlier you said: > Note also that the OOME is successfully generated during object > reallocation a couple of times before (search "run args" in attachments > to the JBS issue). So I suppose in that case it's ok if this one test case allows for no OOME just as long as other test cases still require it. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From ngasson at openjdk.java.net Thu Oct 22 07:09:12 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 22 Oct 2020 07:09:12 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Thu, 22 Oct 2020 04:57:18 GMT, Thomas Stuefe wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for review comments > > src/hotspot/share/code/codeCache.hpp line 194: > >> 192: static void print_summary(outputStream* st, bool detailed = true); // Prints a summary of the code cache usage >> 193: static void log_state(outputStream* st); >> 194: static void write_perf_map(outputStream* st); > > Seems weird for this function to have an outputStream parameter only to write the dump to an unrelated file and ignore the stream for everything but the final message. > > I would either pass in the file name as an option - preferably configurable - and write the last message out here; or just write the whole perf dump to the outputstream itself, piping it to jcmd and let the caller do what he wants with it (e.g. just redirecting). The latter is what most commands do. Not sure how large the perf dump gets though, may be impractical. OK. I think I'll change it so `write_perf_map()` writes to the `outputStream` and then `PerfMapDCmd::execute()` handles redirecting it to a file. I don't think it makes sense to write it directly to the jcmd output though. > src/hotspot/share/code/codeCache.cpp line 1562: > >> 1560: } >> 1561: >> 1562: void CodeCache::write_perf_map(outputStream* st) { > > Could this whole function possibly live inside os/linux in an own file? Or would that expose too many code heap internals? Probably creates too much dependency between the os layer and the codeCache internals? I'll put it all in `#ifdef LINUX` though. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Thu Oct 22 07:09:13 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 22 Oct 2020 07:09:13 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: <-nFOBWmq0LmrYYr-PdeUN20eZ1PXk9XC7wTMyuJ7QEA=.bc5132a8-8a2c-400e-93ad-a940040750d7@github.com> On Wed, 21 Oct 2020 17:57:46 GMT, Chris Plummer wrote: >> I'm not sure, I didn't want to add too much `#ifdef` mess. The code will compile on other platforms, it just won't be called. Better to add `#ifdef`s around all of it? > > Any reason not to have this dcmd supported on all platforms even though the output is really targeted for use with the perf tool on linux? Would a user ever have any other use for the output other than with the perf tool on linux? @plummercj I'm not sure: it's just a text file so could be easily consumed by tools other than perf. But I'm not aware of any tools on other platforms that could use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Thu Oct 22 07:12:23 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 22 Oct 2020 07:12:23 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Thu, 22 Oct 2020 05:00:10 GMT, Thomas Stuefe wrote: > > 1. Like Alexey, I would really wish for an print-at-exit switch. The common naming seems to be xxxAtExit (so not, OnExit). "PrintXxx" seems to be printing stuff out to tty, "DumpXxxx" for writing separate files (e.g. CDS map). So I would name it DumpPerfMapAtExit. > OK, makes sense. > 2. Dumping to /tmp is unexpected for me, I would prefer if the default were dumping to the current directory. That seems to be the default for other files too (cds map, hs-err file etc). > > 3. Not necessary but nice would be a an option to specify location of the dump file. > The `/tmp/perf-.map` is hardcoded into perf though ([see here](https://github.com/torvalds/linux/blob/master/tools/perf/util/map.c#L155)), so I don't think it's useful for the user to be able to change the location. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From rrich at openjdk.java.net Thu Oct 22 07:43:26 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 22 Oct 2020 07:43:26 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 16:45:53 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Merge fix from Richard >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Removed TraceSuspendDebugBits >> - Removed unused method is_ext_suspend_completed_with_lock >> - Utilize handshakes instead of is_thread_fully_suspended > > src/hotspot/share/prims/jvmtiEnv.cpp line 1646: > >> 1644: // java_thread - pre-checked >> 1645: jvmtiError >> 1646: JvmtiEnv::PopFrame(JavaThread* java_thread) { > > So I'm a bit confused why I'm seeing PopFrame() changes here that are > related to @reinrich's EscapeBarrier work. I've seen mention of picking > up a patch during this review from @reinrich so may that's why. I don't > see anything wrong with the changes, but I am confused why they are > here in this review. This change moves code with EscapeBarriers (integrated with #119) into a handshake. That does not work because object reallocation can safepoint. So the EBs are pulled out of the handshake. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Thu Oct 22 07:43:23 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 22 Oct 2020 07:43:23 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> Message-ID: On Wed, 21 Oct 2020 17:03:45 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1454: >> >>> 1452: _state->set_earlyret_pending(); >>> 1453: _state->set_earlyret_oop(ret_ob_h()); >>> 1454: _state->set_earlyret_value(_value, _tos); >> >> Good that these updates are done with a handshake now. Maybe I'm missing s.th. but I don't see synchronization in the older version. > > Agreed. @sspitsyn - This makes me wonder if the lack of > synchronization is the cause of some instability in the > JVM/TI ForceEarlyReturn() testing. > > Update: The old code only made the updates if the thread was fully > suspended so you won't have a race between the requesting thread > and the target thread in that case. Yes, I meant synchronization between racing agent threads. Surely a corner case. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From eosterlund at openjdk.java.net Thu Oct 22 07:49:16 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 22 Oct 2020 07:49:16 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote: >> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >> But we also remove some complicated S/R methods. >> >> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >> >> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >> >> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Fixed merge miss > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Merge fix from Richard > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Removed TraceSuspendDebugBits > - Removed unused method is_ext_suspend_completed_with_lock > - Utilize handshakes instead of is_thread_fully_suspended Just wondering why the escape barrier for force early return uses a stack depth is 0. Either that is wrong, or the escape barrier is not needed in the first place here. I think. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1390: > 1388: return JVMTI_ERROR_OUT_OF_MEMORY; > 1389: } > 1390: if (!eb.deoptimize_objects(0)) { Why is the depth 0 here? That makes no sense to me. My understanding of this is that we have extracted the object deopt that would "normally" (since last week?) be done in JvmtiEnvBase::check_top_frame. And it is walking 1 frame, so shouldn't the depth be 1? ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From eosterlund at openjdk.java.net Thu Oct 22 07:54:17 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 22 Oct 2020 07:54:17 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: <3Ys1ehxM15rARcQvGbk3jOkmZupTUQnxSGYdUETQuGU=.5e2bec65-9188-4cb0-8df3-631dcccfd60a@github.com> On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote: >> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >> But we also remove some complicated S/R methods. >> >> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >> >> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >> >> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Fixed merge miss > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Merge fix from Richard > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Removed TraceSuspendDebugBits > - Removed unused method is_ext_suspend_completed_with_lock > - Utilize handshakes instead of is_thread_fully_suspended src/hotspot/share/prims/jvmtiEnv.cpp line 1663: > 1661: return JVMTI_ERROR_OUT_OF_MEMORY; > 1662: } > 1663: if (!eb.deoptimize_objects(1)) { Oh and why is the depth 1 here, when two frames are deoptimized? Maybe I missed something. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Thu Oct 22 08:00:13 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 22 Oct 2020 08:00:13 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown In-Reply-To: <52rCqsE35JX4M9CR4wco9TNmKArHNlZDPG4hjEKr7FE=.91280ec9-2d2f-48a4-a280-13fe54933e02@github.com> References: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> <1Men5jQJjND5dMM9bWdoor-2l4wDRSopfRZT-13nnkg=.bf5b200e-3b7a-4e09-a426-02fc633c9934@github.com> <52rCqsE35JX4M9CR4wco9TNmKArHNlZDPG4hjEKr7FE=.91280ec9-2d2f-48a4-a280-13fe54933e02@github.com> Message-ID: On Thu, 22 Oct 2020 05:06:43 GMT, Chris Plummer wrote: > Earlier you said: > > > Note also that the OOME is successfully generated during object > > reallocation a couple of times before (search "run args" in attachments > > to the JBS issue). > > So I suppose in that case it's ok if this one test case allows for no OOME just as long as other test cases still require it. With that I wanted to state that the probability to get the OOME is not too bad for meaningful testing. It should be the same for the 3 test cases. What about repeating a test case if the expected OOME is not raised and let it fail after 10x retries? ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From sspitsyn at openjdk.java.net Thu Oct 22 08:06:18 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 22 Oct 2020 08:06:18 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 20:57:03 GMT, Igor Ignatyev wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdb/hidden_class/hc001/hc001.java line 323: >> >>> 321: "xx.yyy/0x111/0x222", >>> 322: "xx./0x111.0x222", >>> 323: "xx.yyy.zzz/" >> >> Why are these indented 8 instead of 4? > > due to the same reasons in the case w/ `fields001`, these lines have 3 unit indentation, 1st for `hc001` class, 2nd for `testInvalidCommands` method, 3rd for `invClassNames` array initialization, so they have 3x4 = 12 spaces. File test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001.java has this change: for (int i = 0; i < threads.length; i++) { reply = jdb.receiveReplyForWithMessageWait(JdbCommand.kill + threads[i] + " " + - DEBUGGEE_EXCEPTIONS + "[" + i + "]", - "killed"); + DEBUGGEE_EXCEPTIONS + "[" + i + "]", + "killed"); } I think, the second line "killed"); has to be aligned with the previous one. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From rehn at openjdk.java.net Thu Oct 22 08:07:22 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 08:07:22 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> Message-ID: On Wed, 21 Oct 2020 16:47:39 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/prims/jvmtiEnv.cpp line 1808: >> >>> 1806: } >>> 1807: if (java_lang_Class::is_primitive(k_mirror)) { >>> 1808: return JVMTI_ERROR_NONE; >> >> The call of JvmtiSuspendControl::print() seems to be eliminated. Ok for me. > > It's not clear to me why the `JvmtiSuspendControl::print()` is being > eliminated. Please explain. The `TraceJVMTICalls` support is so that > someone can diagnose what JVM/TI calls are being made, including > context in some cases, so it seems wrong to delete this call. TraceJVMTICalls is a define local to the file jvmtiEnv.cpp set to false which added some more logging for three of the JVM TI functions. You must first read the code to see if TraceJVMTICalls affects the functions you have an issue with and then change it to true if your lucky it's on of those three. And then you need to recompile. Before commit you need to set to false again. Why not just temporary add the JvmtiSuspendControl::print()/relevant logging instead ? Which you still need to do if it's not one of those three functions. Since this code is not in jvmtiEnv.cpp, we also would need to move TraceJVMTICalls to global scope in some header. Turning TraceJVMTICalls into UL is good idea I guess, but not in scope of this :) >> src/hotspot/share/runtime/thread.cpp line 537: >> >>> 535: // cancelled). Returns true if the thread is externally suspended and >>> 536: // false otherwise. >>> 537: bool JavaThread::is_ext_suspend_completed() { >> >> I'd think `JavaThread::is_ext_suspend_completed` can be removed also (as a separate enhancement). It also duplicates code of the handshake mechanism. Just replace VM_ThreadSuspend with a handshake. > > `is_ext_suspend_completed()` includes code that detects that a thread > that is in `_thread_in_native_trans` and does not yet have a walkable > stack has not completed suspension and we will do some retries in > this function until the target thread gets stable. We have to make sure > that the handshake mechanism has a similar stability guarantee or a > stack walker may fail intermittently. Handshake can only be executed at safepoint poll site, which means if the stack is walkable in all safepoints it is also true for handshakes. And we would be in so much trouble if it were not walkable in all safepoints :) ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 08:07:29 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 08:07:29 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 16:54:48 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Merge fix from Richard >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Removed TraceSuspendDebugBits >> - Removed unused method is_ext_suspend_completed_with_lock >> - Utilize handshakes instead of is_thread_fully_suspended > > src/hotspot/share/prims/jvmtiEnv.cpp line 1718: > >> 1716: MutexLocker mu(JvmtiThreadState_lock); >> 1717: if (java_thread == JavaThread::current()) { >> 1718: op.doit(java_thread, true); > > Please add a comment after the `true` parameter to > indicate the name of the doit() function's parameter, > e.g., `true /* self */`. Fixed > src/hotspot/share/prims/jvmtiEnvBase.cpp line 56: > >> 54: #include "runtime/threadSMR.hpp" >> 55: #include "runtime/vframe.hpp" >> 56: #include "runtime/vframe.inline.hpp" > > When you add `foo.inline.hpp` you delete `foo.hpp` because > the `foo.inline.hpp` file always includes the `foo.hpp` file. Fixed > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1311: > >> 1309: // It is to keep a ret_ob_h handle alive after return to the caller. >> 1310: jvmtiError >> 1311: JvmtiEnvBase::check_top_frame(Thread* current_thread, JavaThread* java_thread, > > Again, it is not clear why these changes to `check_top_frame` are here since they > appear to be related to @reinrich's work. Long story: Before async handshakes was integrate I had a patch which does the same as this. This change was accidentally slipped into async handshakes change-set and was integrated. Richard notice this, I told him he could revert it in his change-set for EB, so he did. But now we need this change, so here it comes once more! VM thread is allowed to execute these handshakes, thus when calling check_top_frame() from SetForceEarlyReturn::doit() it's just a Thread*. > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1398: > >> 1396: SetForceEarlyReturn op(state, value, tos); >> 1397: if (java_thread == current_thread) { >> 1398: op.doit(java_thread, true); > > Please add a comment after the true parameter to > indicate the name of the doit() function's parameter, > e.g., `true /* self */`. Fixed > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1543: > >> 1541: HandleMark hm(current_thread); >> 1542: JavaThread* java_thread = target->as_Java_thread(); >> 1543: > > This would be useful here: > > `assert(_state->get_thread() == java_thread, "Must be");` Fixed. > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1570: > >> 1568: >> 1569: ResourceMark rm(current_thread); >> 1570: // Check if there are more than one Java frame in this thread, that the top two frames > > typo: s/are more/is more/ Fixed > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1642: > >> 1640: >> 1641: if (!self) { >> 1642: if (!java_thread->is_external_suspend()) { > > You could join these two if-statements with `&&` and have > one less indenting level... Fixed > src/hotspot/share/prims/jvmtiEnvBase.hpp line 361: > >> 359: _tos(tos) {} >> 360: void do_thread(Thread *target) { >> 361: doit(target, false); > > Please add a comment after the true parameter to > indicate the name of the doit() function's parameter, > e.g., `false /* self */`. Fixed > src/hotspot/share/prims/jvmtiEnvBase.hpp line 395: > >> 393: _depth(depth) {} >> 394: void do_thread(Thread *target) { >> 395: doit(target, false); > > Please add a comment after the true parameter to > indicate the name of the doit() function's parameter, > e.g., `false /* self */`. Fixed > src/hotspot/share/runtime/deoptimization.cpp line 1755: > >> 1753: thread->is_handshake_safe_for(Thread::current()) || >> 1754: SafepointSynchronize::is_at_safepoint(), >> 1755: "can only deoptimize other thread at a safepoint"); > > Should that now be: `safepoint/handshake`?? Fixed > src/hotspot/share/runtime/thread.cpp line 698: > >> 696: RememberProcessedThread rpt(this); >> 697: oops_do_no_frames(f, cf); >> 698: oops_do_frames(f, cf); > > In the comment above: > // ... If we were > // called by wait_for_ext_suspend_completion(), then it > // will be doing the retries so we don't have to. > `wait_for_ext_suspend_completion()` has been deleted so the > comment needs work. I just delete the no longer relevant parts. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 08:07:30 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 08:07:30 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> Message-ID: On Thu, 22 Oct 2020 06:50:37 GMT, Richard Reingruber wrote: >> Agreed. @sspitsyn - This makes me wonder if the lack of >> synchronization is the cause of some instability in the >> JVM/TI ForceEarlyReturn() testing. >> >> Update: The old code only made the updates if the thread was fully >> suspended so you won't have a race between the requesting thread >> and the target thread in that case. > > Yes, I meant synchronization between racing agent threads. Surely a corner case. Since we do not hold Threads_lock nor SR_lock nothing is stopping the resume at this point AFAICT. Now this might be illegal, but it can happen if you are not really careful, specially in test like Kitchensink where two modules might use S/R on the same thread. Also if two threads calling this, the second thread might have passed: if (_state->is_earlyret_pending()) { When we do the setting: _state->set_earlyret_pending(); But now it's protected, even if this never manifested as bug, now we sure it will not. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 08:07:30 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 08:07:30 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> Message-ID: <6edg514T7j4mK6ugFkgnj9hhe3_Unk5V7zgrOBTAg5A=.2203f384-6baa-417f-9da9-73e00fb5406e@github.com> On Wed, 21 Oct 2020 22:57:26 GMT, David Holmes wrote: >> Especially if an assert() is added above on L1543. > > Agreed - this code has become confused about what thread variables are present and their relationship. Fixed and moved assert. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 08:07:30 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 08:07:30 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 22:57:59 GMT, David Holmes wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1661: >> >>> 1659: assert(vf->frame_pointer() != NULL, "frame pointer mustn't be NULL"); >>> 1660: if (java_thread->is_exiting() || java_thread->threadObj() == NULL) { >>> 1661: return; >> >> What's the `_result` value if this `return` executes? > > The default "not alive" value. Added comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 08:07:32 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 08:07:32 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> References: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> Message-ID: On Wed, 21 Oct 2020 14:02:59 GMT, Richard Reingruber wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Merge fix from Richard >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Removed TraceSuspendDebugBits >> - Removed unused method is_ext_suspend_completed_with_lock >> - Utilize handshakes instead of is_thread_fully_suspended > > src/hotspot/share/prims/jvmtiEnvBase.hpp line 310: > >> 308: GrowableArray *owned_monitors_list); >> 309: static jvmtiError check_top_frame(Thread* current_thread, JavaThread* java_thread, >> 310: jvalue value, TosState tos, Handle* ret_ob_h); > > Maybe fix indentation? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 08:07:32 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 08:07:32 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: <0yF3nXkvKHHTheoHvF4IQJ9v98AjHl-7R9tSo1qrOec=.367302e8-9414-455d-a601-046cdf5a40c8@github.com> References: <27LjwNE2Xl_ceCaXzFOuF9slhZklqN9TvLt0Vsw2sMM=.9c9d6a08-d19c-4ed3-af8f-890ad1a0bdc5@github.com> <0yF3nXkvKHHTheoHvF4IQJ9v98AjHl-7R9tSo1qrOec=.367302e8-9414-455d-a601-046cdf5a40c8@github.com> Message-ID: On Wed, 21 Oct 2020 14:20:21 GMT, Richard Reingruber wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 1771: >> >>> 1769: Deoptimization::deoptimize_frame_internal(thread, id, reason); >>> 1770: } else { >>> 1771: VM_DeoptimizeFrame deopt(thread, id, reason); >> >> I guess VM_DeoptimizeFrame can be replaced with a handshake too now. > > Not in this pr of course :) I think so. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 08:07:34 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 08:07:34 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 20:31:27 GMT, Erik ?sterlund wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Merge fix from Richard >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Removed TraceSuspendDebugBits >> - Removed unused method is_ext_suspend_completed_with_lock >> - Utilize handshakes instead of is_thread_fully_suspended > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1390: > >> 1388: return JVMTI_ERROR_OUT_OF_MEMORY; >> 1389: } >> 1390: if (!eb.deoptimize_objects(0)) { > > Why is the depth 0 here? That makes no sense to me. My understanding of this is that we have extracted the object deopt that would "normally" (since last week?) be done in JvmtiEnvBase::check_top_frame. And it is walking 1 frame, so shouldn't the depth be 1? @reinrich did I mess something up when merging this in? > src/hotspot/share/prims/jvmtiEnv.cpp line 1663: > >> 1661: return JVMTI_ERROR_OUT_OF_MEMORY; >> 1662: } >> 1663: if (!eb.deoptimize_objects(1)) { > > Oh and why is the depth 1 here, when two frames are deoptimized? Maybe I missed something. @reinrich did I mess something up when merging this in? ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Thu Oct 22 08:17:16 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 22 Oct 2020 08:17:16 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 08:04:44 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1390: >> >>> 1388: return JVMTI_ERROR_OUT_OF_MEMORY; >>> 1389: } >>> 1390: if (!eb.deoptimize_objects(0)) { >> >> Why is the depth 0 here? That makes no sense to me. My understanding of this is that we have extracted the object deopt that would "normally" (since last week?) be done in JvmtiEnvBase::check_top_frame. And it is walking 1 frame, so shouldn't the depth be 1? > > @reinrich did I mess something up when merging this in? Stack frames are counted beginning at 0. The top frame has depth 0. So object deoptimization happens in the top frame. Still the used method is not optimal because it assumes that objects of frames within the given depth are accessed and their escape state is changed. But potentially caller methods optimized on the escape state therefore it searches for caller frames passing ArgEscape objects and deoptimizes these too. With ForceEarlyReturn no objects are accessed but it is so uncommon that I did not bother optimizing this. Should I? ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Thu Oct 22 08:26:17 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 22 Oct 2020 08:26:17 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 08:04:48 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/jvmtiEnv.cpp line 1663: >> >>> 1661: return JVMTI_ERROR_OUT_OF_MEMORY; >>> 1662: } >>> 1663: if (!eb.deoptimize_objects(1)) { >> >> Oh and why is the depth 1 here, when two frames are deoptimized? Maybe I missed something. > > @reinrich did I mess something up when merging this in? Depth 1 means top frame and its caller. In UpdateForPopTopFrameClosure::doit() line 1606(?) the 2 top frames are deoptimized. Reallocating objects while a frame pop request is processed does not work if reallocation fails therefore we use an EscapeBarrier to eagerly reallocate objects beforehand. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Thu Oct 22 08:45:18 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 22 Oct 2020 08:45:18 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: <1Z_x_ChC5sDgWgl7FPcgZMwuxi2g3yNlbQPb5Ah93BY=.b07aeb23-cd2c-4628-bca8-1c9530520688@github.com> On Thu, 22 Oct 2020 08:14:47 GMT, Richard Reingruber wrote: >> @reinrich did I mess something up when merging this in? > > Stack frames are counted beginning at 0. The top frame has depth 0. So object deoptimization happens in the top frame. > > Still the used method is not optimal because it assumes that objects of frames within the given depth are accessed and their escape state is changed. But potentially caller methods optimized on the escape state therefore it searches for caller frames passing ArgEscape objects and deoptimizes these too. With ForceEarlyReturn no objects are accessed but it is so uncommon that I did not bother optimizing this. Should I? @robehn you haven't messed up. Hope I havn't either. I've tested ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg:hotspot_serviceability 197 197 0 0 jtreg:test/jdk:jdk_svc 1176 1176 0 0 jtreg:test/jdk:jdk_jdi 174 174 0 0 jtreg:test/hotspot/jtreg:vmTestbase_nsk_jdi 1141 1141 0 0 jtreg:test/hotspot/jtreg:vmTestbase_nsk_jvmti 648 648 0 0 jtreg:test/hotspot/jtreg:vmTestbase_nsk_jdwp 113 113 0 0 ============================== TEST SUCCESS jdk_jdi now includes jdk/com/sun/jdi/EATests.java which tests PopFrame/ForceEarlyReturn with object reallocation with and without reallocation failures. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From sspitsyn at openjdk.java.net Thu Oct 22 08:51:12 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 22 Oct 2020 08:51:12 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 08:03:15 GMT, Serguei Spitsyn wrote: >> due to the same reasons in the case w/ `fields001`, these lines have 3 unit indentation, 1st for `hc001` class, 2nd for `testInvalidCommands` method, 3rd for `invClassNames` array initialization, so they have 3x4 = 12 spaces. > > File test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001.java has this change: > > for (int i = 0; i < threads.length; i++) { > reply = jdb.receiveReplyForWithMessageWait(JdbCommand.kill + threads[i] + " " + > - DEBUGGEE_EXCEPTIONS + "[" + i + "]", > - "killed"); > + DEBUGGEE_EXCEPTIONS + "[" + i + "]", > + "killed"); > } > I think, the second line "killed"); has to be aligned with the previous one. > Also, I feels like this change makes the code to be less readable: > reply = jdb.receiveReplyForWithMessageWait(JdbCommand.eval + DEBUGGEE_RESULT, > - DEBUGGEE_RESULT + " ="); > + DEBUGGEE_RESULT + " ="); Hi Igor, Overall, it is great. Your formatting tool seems to be AI. ?? This update fixes a lot of formatting issues. I have no more comments so far. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From rrich at openjdk.java.net Thu Oct 22 08:53:13 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 22 Oct 2020 08:53:13 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 08:23:38 GMT, Richard Reingruber wrote: >> @reinrich did I mess something up when merging this in? > > Depth 1 means top frame and its caller. In UpdateForPopTopFrameClosure::doit() line 1606(?) the 2 top frames are deoptimized. Reallocating objects while a frame pop request is processed does not work if reallocation fails therefore we use an EscapeBarrier to eagerly reallocate objects beforehand. @fisk for PopFrame the top frame needs to be deoptimized (if compiled) to be able to actually remove it when the thread is resumed. Its caller needs to be deoptimized to be able restart the call. For ForceEarlyReturn it is not necessary to restart. The target can return to a compiled caller and continue executing compiled code. So the caller frame is not deoptimized. @robehn nothing is messed up. Thanks again for doing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From sjohanss at openjdk.java.net Thu Oct 22 08:58:17 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 22 Oct 2020 08:58:17 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v4] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 19:49:03 GMT, Stefan Johansson wrote: >> Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 565: > >> 563: size_t old_gen_used = ParallelScavengeHeap::heap()->old_gen()->used_in_bytes(); >> 564: size_t block_size = ParallelScavengeHeap::heap()->old_gen()->iterate_block_size(); >> 565: uint n_blocks_in_old = old_gen_used / block_size + 1; > > Instead of doing this calculation here, what do you think about making `iterate_block_size()` a constant in `PSOldGen` and instead adding a function that returns the number of blocks available, something like: > `iterable_blocks()` One additional thing here, the `n_blocks_in_old` calculation will return one extra block when old_gen_used is a multiple of block_size. : Here's an alternative: uint n_blocks_in_old = (old_gen_used + block_size - 1) / block_size; ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From sjohanss at openjdk.java.net Thu Oct 22 08:58:15 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 22 Oct 2020 08:58:15 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v4] In-Reply-To: References: Message-ID: <6yTg9zMAJ3rXyu8u5vtH7_Sah9EYWd0pXyaUqwhFBAQ=.64738637-681e-4dd9-9bfc-74d5c614892e@github.com> On Mon, 19 Oct 2020 13:09:34 GMT, Lin Zang wrote: >> - Parallel heap iteration support for PSS >> - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 > > Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Took a second look today and found two additional problems. I would also be interested in what kind of testing you've done with this patch. src/hotspot/share/gc/parallel/psOldGen.cpp line 199: > 197: > 198: // iterate objects in block. > 199: HeapWord* end = MIN2(top, begin + _iterate_block_size); `_iterate_block_size` is a size in bytes (or at least you use it like a size in bytes when calculating the number of blocks), so before you can add it you need to convert it to a size in words like this: Suggestion: size_t block_word_size = _iterate_block_size / HeapWordSize; HeapWord* begin = bottom + block_index * block_word_size; assert((block_word_size % (ObjectStartArray::block_size)) == 0, "BLOCK SIZE not a multiple of start_array block"); // iterate objects in block. HeapWord* end = MIN2(top, begin + block_word_size); ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/25 From eosterlund at openjdk.java.net Thu Oct 22 10:07:18 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 22 Oct 2020 10:07:18 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: <1Z_x_ChC5sDgWgl7FPcgZMwuxi2g3yNlbQPb5Ah93BY=.b07aeb23-cd2c-4628-bca8-1c9530520688@github.com> References: <1Z_x_ChC5sDgWgl7FPcgZMwuxi2g3yNlbQPb5Ah93BY=.b07aeb23-cd2c-4628-bca8-1c9530520688@github.com> Message-ID: On Thu, 22 Oct 2020 08:42:40 GMT, Richard Reingruber wrote: >> Stack frames are counted beginning at 0. The top frame has depth 0. So object deoptimization happens in the top frame. >> >> Still the used method is not optimal because it assumes that objects of frames within the given depth are accessed and their escape state is changed. But potentially caller methods optimized on the escape state therefore it searches for caller frames passing ArgEscape objects and deoptimizes these too. With ForceEarlyReturn no objects are accessed but it is so uncommon that I did not bother optimizing this. Should I? > > @robehn you haven't messed up. Hope I havn't either. I've tested > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg:hotspot_serviceability 197 197 0 0 > jtreg:test/jdk:jdk_svc 1176 1176 0 0 > jtreg:test/jdk:jdk_jdi 174 174 0 0 > jtreg:test/hotspot/jtreg:vmTestbase_nsk_jdi 1141 1141 0 0 > jtreg:test/hotspot/jtreg:vmTestbase_nsk_jvmti 648 648 0 0 > jtreg:test/hotspot/jtreg:vmTestbase_nsk_jdwp 113 113 0 0 > ============================== > TEST SUCCESS > jdk_jdi now includes jdk/com/sun/jdi/EATests.java which tests PopFrame/ForceEarlyReturn with object reallocation with and without reallocation failures. Ah. I see now the loop uses <= instead of <. So my reasoning was right but off by 1. Passing in 0 really means deopt 1 frame. Which means everything is fine and working the way I expect it to. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From eosterlund at openjdk.java.net Thu Oct 22 10:07:18 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 22 Oct 2020 10:07:18 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote: >> The main point of this change-set is to make it easier to implement S/R on top of handshakes. >> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). >> But we also remove some complicated S/R methods. >> >> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. >> >> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. >> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. >> >> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Fixed merge miss > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Merge fix from Richard > - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended > - Removed TraceSuspendDebugBits > - Removed unused method is_ext_suspend_completed_with_lock > - Utilize handshakes instead of is_thread_fully_suspended Looks good. Awesome fix IMO. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 10:17:26 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 10:17:26 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v4] In-Reply-To: References: Message-ID: > The main point of this change-set is to make it easier to implement S/R on top of handshakes. > Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). > But we also remove some complicated S/R methods. > > We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. > > TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. > But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. > > Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge - Review updates - Fixed merge miss - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended - Merge fix from Richard - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended - Removed TraceSuspendDebugBits - Removed unused method is_ext_suspend_completed_with_lock - Utilize handshakes instead of is_thread_fully_suspended ------------- Changes: https://git.openjdk.java.net/jdk/pull/729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=729&range=03 Stats: 611 lines in 6 files changed: 174 ins; 376 del; 61 mod Patch: https://git.openjdk.java.net/jdk/pull/729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/729/head:pull/729 PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 10:31:16 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 10:31:16 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: <1Z_x_ChC5sDgWgl7FPcgZMwuxi2g3yNlbQPb5Ah93BY=.b07aeb23-cd2c-4628-bca8-1c9530520688@github.com> Message-ID: On Thu, 22 Oct 2020 10:04:01 GMT, Erik ?sterlund wrote: >> @robehn you haven't messed up. Hope I havn't either. I've tested >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:hotspot_serviceability 197 197 0 0 >> jtreg:test/jdk:jdk_svc 1176 1176 0 0 >> jtreg:test/jdk:jdk_jdi 174 174 0 0 >> jtreg:test/hotspot/jtreg:vmTestbase_nsk_jdi 1141 1141 0 0 >> jtreg:test/hotspot/jtreg:vmTestbase_nsk_jvmti 648 648 0 0 >> jtreg:test/hotspot/jtreg:vmTestbase_nsk_jdwp 113 113 0 0 >> ============================== >> TEST SUCCESS >> jdk_jdi now includes jdk/com/sun/jdi/EATests.java which tests PopFrame/ForceEarlyReturn with object reallocation with and without reallocation failures. > > Ah. I see now the loop uses <= instead of <. So my reasoning was right but off by 1. Passing in 0 really means deopt 1 frame. Which means everything is fine and working the way I expect it to. Great ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 10:31:17 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 10:31:17 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 08:50:54 GMT, Richard Reingruber wrote: >> Depth 1 means top frame and its caller. In UpdateForPopTopFrameClosure::doit() line 1606(?) the 2 top frames are deoptimized. Reallocating objects while a frame pop request is processed does not work if reallocation fails therefore we use an EscapeBarrier to eagerly reallocate objects beforehand. > > @fisk for PopFrame the top frame needs to be deoptimized (if compiled) to be able to actually remove it when the thread is resumed. Its caller needs to be deoptimized to be able restart the call. For ForceEarlyReturn it is not necessary to restart. The target can return to a compiled caller and continue executing compiled code. So the caller frame is not deoptimized. > > @robehn nothing is messed up. Thanks again for doing it. Great! ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 10:47:20 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 10:47:20 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: References: Message-ID: <4WNbKclJp0jLscBp5IV84_z1gRX8TWH1SSWPHnaR12Y=.bd000576-9225-4ea6-9561-091e41bf427e@github.com> On Thu, 22 Oct 2020 10:04:48 GMT, Erik ?sterlund wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Fixed merge miss >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Merge fix from Richard >> - Merge branch 'master' into 8223312-Utilize-handshakes-instead-of-is_thread_fully_suspended >> - Removed TraceSuspendDebugBits >> - Removed unused method is_ext_suspend_completed_with_lock >> - Utilize handshakes instead of is_thread_fully_suspended > > Looks good. Awesome fix IMO. Passes my local testing: open/test/jdk/com/sun/jdi/EATests.java, nsk_jvmti, nsk_jdi, jdk_jdi, jck:vm. Still running t1-t5 in test system. I will be integrating later today, so the ZGC/EscapeBarrier issue can be resolved (which is semi-dependent on this). Thanks @dholmes-ora, @dcubed-ojdk, @reinrich, @fisk ! ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rrich at openjdk.java.net Thu Oct 22 13:10:10 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 22 Oct 2020 13:10:10 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown In-Reply-To: References: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> <1Men5jQJjND5dMM9bWdoor-2l4wDRSopfRZT-13nnkg=.bf5b200e-3b7a-4e09-a426-02fc633c9934@github.com> <52rCqsE35JX4M9CR4wco9TNmKArHNlZDPG4hjEKr7FE=.91280ec9-2d2f-48a4-a280-13fe54933e02@github.com> Message-ID: On Thu, 22 Oct 2020 07:57:32 GMT, Richard Reingruber wrote: >>> The new LinkedListOfLongArrays is created by renaming LinkedList to >>> LinkedListOfLongArrays. The new LinkedList is a list node without payload, so it >>> is smaller than a LinkedListOfLongArrays node. I try to fill the last free >>> blocks with these. But yeah, this won't make that much of a difference. >> >> Ok. However, since you can't reproduce the initial problem it's hard to say if this will fix it. You would need to remove it from the problem list with this PR and see what happens. >> >> Earlier you said: >> >>> Note also that the OOME is successfully generated during object >>> reallocation a couple of times before (search "run args" in attachments >>> to the JBS issue). >> >> So I suppose in that case it's ok if this one test case allows for no OOME just as long as other test cases still require it. > >> Earlier you said: >> >> > Note also that the OOME is successfully generated during object >> > reallocation a couple of times before (search "run args" in attachments >> > to the JBS issue). >> >> So I suppose in that case it's ok if this one test case allows for no OOME just as long as other test cases still require it. > > With that I wanted to state that the probability to get the OOME is not too bad > for meaningful testing. It should be the same for the 3 test cases. > > What about repeating a test case if the expected OOME is not raised and let it > fail after 10x retries? You mentioned the possibility that the OOME is not thrown because it is another thread that consumes all memory than the one calling forceEarlyReturn() which is supposed to fail with OOME. TLAB could be an issue then. In general GC could have a heuristic in place to raise OOME in greedy threads when another thread would still be able to allocate successfully. I think I could change the debugger part to call consumeAllMemory() in the debuggee. This should be executed in the same jdwp agent thread as the later forceEarlyReturn. But honestly I don't think it is worth it and I cannot even test if it fixes the issues. I'd prefer to skip the 3 test cases if running with ZGC. Please let me know what you prefer. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From cjplummer at openjdk.java.net Thu Oct 22 14:32:14 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 22 Oct 2020 14:32:14 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown In-Reply-To: References: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> <1Men5jQJjND5dMM9bWdoor-2l4wDRSopfRZT-13nnkg=.bf5b200e-3b7a-4e09-a426-02fc633c9934@github.com> <52rCqsE35JX4M9CR4wco9TNmKArHNlZDPG4hjEKr7FE=.91280ec9-2d2f-48a4-a280-13fe54933e02@github.com> Message-ID: On Thu, 22 Oct 2020 13:07:32 GMT, Richard Reingruber wrote: > But honestly I don't think it is worth it and I cannot even test if it fixes the issues. I'd prefer to skip the 3 test cases if running with ZGC. Please let me know what you prefer. That's one option if this only happens with ZGC. You also mentioned doing retries. I would only suggest that if you think you can limit the chances of the OOME not happening to be so unlikely that we are no likely to ever see it happen. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From rehn at openjdk.java.net Thu Oct 22 15:23:27 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 15:23:27 GMT Subject: Integrated: 8223312: Utilize handshakes instead of is_thread_fully_suspended In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 09:59:34 GMT, Robbin Ehn wrote: > The main point of this change-set is to make it easier to implement S/R on top of handshakes. > Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality). > But we also remove some complicated S/R methods. > > We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is. > > TraceSuspendDebugBits have an ifdef, but in both cases it now just returns. > But I was unsure if I should remove now or when is_ext_suspend_completed() is removed. > > Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs. This pull request has now been integrated. Changeset: 4634dbef Author: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/4634dbef Stats: 611 lines in 6 files changed: 174 ins; 376 del; 61 mod 8223312: Utilize handshakes instead of is_thread_fully_suspended Reviewed-by: dholmes, rrich, dcubed, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From rehn at openjdk.java.net Thu Oct 22 15:23:26 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Oct 2020 15:23:26 GMT Subject: RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3] In-Reply-To: <4WNbKclJp0jLscBp5IV84_z1gRX8TWH1SSWPHnaR12Y=.bd000576-9225-4ea6-9561-091e41bf427e@github.com> References: <4WNbKclJp0jLscBp5IV84_z1gRX8TWH1SSWPHnaR12Y=.bd000576-9225-4ea6-9561-091e41bf427e@github.com> Message-ID: <9Vw23OOV_Gtf1aNVH3jcDccAS97sDwOGOZ7UO9D0m2s=.d79acae3-6cf8-4aab-af7d-a6c137a7809d@github.com> On Thu, 22 Oct 2020 10:44:21 GMT, Robbin Ehn wrote: >> Looks good. Awesome fix IMO. > > Passes my local testing: open/test/jdk/com/sun/jdi/EATests.java, nsk_jvmti, nsk_jdi, jdk_jdi, jck:vm. > Still running t1-t5 in test system. > > I will be integrating later today, so the ZGC/EscapeBarrier issue can be resolved (which is semi-dependent on this). > > Thanks @dholmes-ora, @dcubed-ojdk, @reinrich, @fisk ! T1-5 looked good. ------------- PR: https://git.openjdk.java.net/jdk/pull/729 From cjplummer at openjdk.java.net Thu Oct 22 15:43:12 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 22 Oct 2020 15:43:12 GMT Subject: RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2] In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 08:48:20 GMT, Serguei Spitsyn wrote: >> File test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001.java has this change: >> >> for (int i = 0; i < threads.length; i++) { >> reply = jdb.receiveReplyForWithMessageWait(JdbCommand.kill + threads[i] + " " + >> - DEBUGGEE_EXCEPTIONS + "[" + i + "]", >> - "killed"); >> + DEBUGGEE_EXCEPTIONS + "[" + i + "]", >> + "killed"); >> } >> I think, the second line "killed"); has to be aligned with the previous one. >> Also, I feels like this change makes the code to be less readable: >> reply = jdb.receiveReplyForWithMessageWait(JdbCommand.eval + DEBUGGEE_RESULT, >> - DEBUGGEE_RESULT + " ="); >> + DEBUGGEE_RESULT + " ="); > > Hi Igor, > > Overall, it is great. Your formatting tool seems to be AI. ?? > This update fixes a lot of formatting issues. > I have no more comments so far. Regarding the "killed" formatting, I think the reason for it is the 8 space "line continuation rule". The 2nd line is a actually a line continuation of a line continuation, so it gets indented and extra 16 spaces. The 3rd line is just a single line continuation, so gets indented just an extra 8. I think what would help to clean this up is to move the first argument onto a newline, which would just be indented an extra 8. That way it won't be broken up over multiple lines, and will also be inline with the "killed" argument. For the 2nd case above, I also think this is less readable than the original. I personally like it if you align all arguments with the first one, even if it leads to a non-standard indentation. If you want subsequent arguments to use the 8 space line continuation rule, then I suggest whenever arguments are on multiple lines that you always place the first argument on a new line so all arguments are aligned together. ------------- PR: https://git.openjdk.java.net/jdk/pull/689 From jjg at openjdk.java.net Thu Oct 22 17:29:21 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 22 Oct 2020 17:29:21 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag Message-ID: The change is (just) to remove legacy usages of a JDK-private custom tag. ------------- Commit messages: - JDK-8255262: Remove use of legacy custom @spec tag Changes: https://git.openjdk.java.net/jdk/pull/814/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=814&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255262 Stats: 209 lines in 69 files changed: 0 ins; 209 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/814.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/814/head:pull/814 PR: https://git.openjdk.java.net/jdk/pull/814 From lancea at openjdk.java.net Thu Oct 22 17:35:15 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 22 Oct 2020 17:35:15 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. looks fine ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/814 From iris at openjdk.java.net Thu Oct 22 17:46:16 2020 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 22 Oct 2020 17:46:16 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: <-NCS5lF0mdeaDq1CyQYTrh0gGVozPafltjNYsEpO488=.d795b2ec-acc2-4c06-8434-757b2095e386@github.com> On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Nice clean-up. ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/814 From mr at openjdk.java.net Thu Oct 22 17:46:15 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 22 Oct 2020 17:46:15 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. As the creator of these tags many moons ago, I approve this change. ------------- Marked as reviewed by mr (Lead). PR: https://git.openjdk.java.net/jdk/pull/814 From darcy at openjdk.java.net Thu Oct 22 17:46:18 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 22 Oct 2020 17:46:18 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: <5hlum1g6yK7pF3TkDMBvYSlK0Ca3bVh1VM3XJUVAvCk=.93e60ef2-400c-4775-a4c5-1f290e14ed57@github.com> On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/814 From alanb at openjdk.java.net Thu Oct 22 17:46:17 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 22 Oct 2020 17:46:17 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/814 From mchung at openjdk.java.net Thu Oct 22 17:56:16 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 22 Oct 2020 17:56:16 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/814 From jjg at openjdk.java.net Thu Oct 22 19:49:22 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 22 Oct 2020 19:49:22 GMT Subject: Integrated: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. This pull request has now been integrated. Changeset: 0aa3c925 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/0aa3c925 Stats: 209 lines in 69 files changed: 0 ins; 209 del; 0 mod 8255262: Remove use of legacy custom @spec tag Reviewed-by: lancea, mr, iris, alanb, darcy, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/814 From rrich at openjdk.java.net Thu Oct 22 20:35:29 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 22 Oct 2020 20:35:29 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3] In-Reply-To: References: Message-ID: > The following test cases try to provoke VMOutOfMemoryException during object reallocation: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > This is not 100% reliable therefore it should not be treated as test failure if no oom was raised. Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Skip test cases expecting OOMEs if running with ZGC. - Merge branch 'master' into JDK-8255072-eatests-oom-not-thrown - Make OOME more reliable and skip test cases if it is not expected because scalar replacement is disabled - 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/775/files - new: https://git.openjdk.java.net/jdk/pull/775/files/4196a421..33ceb741 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=01-02 Stats: 28553 lines in 409 files changed: 23836 ins; 3073 del; 1644 mod Patch: https://git.openjdk.java.net/jdk/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/775/head:pull/775 PR: https://git.openjdk.java.net/jdk/pull/775 From rrich at openjdk.java.net Thu Oct 22 20:41:17 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 22 Oct 2020 20:41:17 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown In-Reply-To: References: <5GDk4rvGwtJWM3ce_rvtipcJNzL2FS0puc6eM5HbVt8=.6f3b584e-60c0-4463-88c2-cfa45e7fde5f@github.com> <1Men5jQJjND5dMM9bWdoor-2l4wDRSopfRZT-13nnkg=.bf5b200e-3b7a-4e09-a426-02fc633c9934@github.com> <52rCqsE35JX4M9CR4wco9TNmKArHNlZDPG4hjEKr7FE=.91280ec9-2d2f-48a4-a280-13fe54933e02@github.com> Message-ID: On Thu, 22 Oct 2020 14:29:28 GMT, Chris Plummer wrote: >> You mentioned the possibility that the OOME is not thrown because it is another thread that consumes all memory than the one calling forceEarlyReturn() which is supposed to fail with OOME. TLAB could be an issue then. In general GC could have a heuristic in place to raise OOME in greedy threads when another thread would still be able to allocate successfully. I think I could change the debugger part to call consumeAllMemory() in the debuggee. This should be executed in the same jdwp agent thread as the later forceEarlyReturn. >> >> But honestly I don't think it is worth it and I cannot even test if it fixes the issues. I'd prefer to skip the 3 test cases if running with ZGC. Please let me know what you prefer. > >> But honestly I don't think it is worth it and I cannot even test if it fixes the issues. I'd prefer to skip the 3 test cases if running with ZGC. Please let me know what you prefer. > > That's one option if this only happens with ZGC. You also mentioned doing retries. I would only suggest that if you think you can limit the chances of the OOME not happening to be so unlikely that we are no likely to ever see it happen. With the last commit the combined change is - The 3 problematic test cases are skipped if ZGC is selected. - They are also skipped if no OOME during object reallocation can be expected because allocations are not eliminated. - In consumeAllMemory, as a last step, empty LinkedList nodes are created without long array to fill up small blocks of free memory. - EATests.java is removed from the problem list for ZGC. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From cjplummer at openjdk.java.net Thu Oct 22 23:09:14 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 22 Oct 2020 23:09:14 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3] In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 20:35:29 GMT, Richard Reingruber wrote: >> The following test cases try to provoke VMOutOfMemoryException during object reallocation: >> >> EAPopFrameNotInlinedReallocFailure >> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure >> EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure >> >> This is not 100% reliable therefore it should not be treated as test failure if no oom was raised. > > Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Skip test cases expecting OOMEs if running with ZGC. > - Merge branch 'master' into JDK-8255072-eatests-oom-not-thrown > - Make OOME more reliable and skip test cases if it is not expected because scalar replacement is disabled > - 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/775 From rrich at openjdk.java.net Fri Oct 23 08:03:40 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 23 Oct 2020 08:03:40 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3] In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 23:06:10 GMT, Chris Plummer wrote: > > > Looks good. Thank you. I'll wait for a second review assuming it's required. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From cjplummer at openjdk.java.net Fri Oct 23 08:18:35 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 23 Oct 2020 08:18:35 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3] In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 08:00:49 GMT, Richard Reingruber wrote: > Thank you. I'll wait for a second review assuming it's required. You might want to add the compiler and/or gc teams to the review ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From rrich at openjdk.java.net Fri Oct 23 09:33:36 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 23 Oct 2020 09:33:36 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3] In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 08:15:34 GMT, Chris Plummer wrote: >>> >>> >>> Looks good. >> >> Thank you. I'll wait for a second review assuming it's required. > >> Thank you. I'll wait for a second review assuming it's required. > > You might want to add the compiler and/or gc teams to the review Following @plummercj advice to add compiler/gc teams. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From sgehwolf at openjdk.java.net Fri Oct 23 13:36:43 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 23 Oct 2020 13:36:43 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code for Java [v2] In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: <_FwWIYpuGSriKjwb_qnhnA6ScUatrTdSy4j2s2E7ybY=.db63ce7a-65f4-41e6-a107-5419cf0faee3@github.com> > Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). This patch alleviates that. > > Thoughts? Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8253939: [TESTBUG] Increase coverage of the cgroups detection code for Java ------------- Changes: https://git.openjdk.java.net/jdk/pull/609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=01 Stats: 40 lines in 1 file changed: 27 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/609/head:pull/609 PR: https://git.openjdk.java.net/jdk/pull/609 From sgehwolf at openjdk.java.net Fri Oct 23 15:51:47 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 23 Oct 2020 15:51:47 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code [v3] In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: <5Jk_4mxRk_8rIaxUY9NhUNhOmjdIuRuV-KWzeSrLkaI=.07c9a141-6335-4e52-8aff-3fcbfce02a17@github.com> > Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). > > When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. > > Thoughts? Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8253939: [TESTBUG] Increase coverage of the cgroups detection code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/609/files - new: https://git.openjdk.java.net/jdk/pull/609/files/a122958f..44362211 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=01-02 Stats: 107 lines in 2 files changed: 107 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/609/head:pull/609 PR: https://git.openjdk.java.net/jdk/pull/609 From cjplummer at openjdk.java.net Fri Oct 23 22:36:39 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 23 Oct 2020 22:36:39 GMT Subject: RFR: 8252117: com/sun/jdi/BadHandshakeTest.java failed with "ConnectException: Connection refused: connect" In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 00:00:17 GMT, Alex Menkov wrote: > Please review the fix for BadHandshakeTest. > Summary: > The test verifies that bad (testcase1) or incomplete (testcase2) handshake does not cause debuggee termination. > To check this it tries to attach to the debuggee again (connect in testcase2 is also verification for testcase1) > > The fix adds reply logic to the last attach (similar to retry logic in testcase2) Other than the one comment I noted, the changes look good. Was the failure rate high enough that you've been able to prove your fix works? test/jdk/com/sun/jdi/BadHandshakeTest.java line 159: > 157: } > 158: > 159: // get the debuggee some time to exit before forcibly terminate it "give", not "get". Also, "terminating", not "terminate". ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/789 From amenkov at openjdk.java.net Fri Oct 23 22:44:50 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 23 Oct 2020 22:44:50 GMT Subject: RFR: 8252117: com/sun/jdi/BadHandshakeTest.java failed with "ConnectException: Connection refused: connect" [v2] In-Reply-To: References: Message-ID: > Please review the fix for BadHandshakeTest. > Summary: > The test verifies that bad (testcase1) or incomplete (testcase2) handshake does not cause debuggee termination. > To check this it tries to attach to the debuggee again (connect in testcase2 is also verification for testcase1) > > The fix adds reply logic to the last attach (similar to retry logic in testcase2) Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Fix the comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/789/files - new: https://git.openjdk.java.net/jdk/pull/789/files/26c5e4be..b16810b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=789&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=789&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/789.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/789/head:pull/789 PR: https://git.openjdk.java.net/jdk/pull/789 From lzang at openjdk.java.net Mon Oct 26 03:12:37 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 26 Oct 2020 03:12:37 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v4] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 20:56:01 GMT, Stefan Johansson wrote: >> Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 318: > >> 316: static const uint eden_index = 0; >> 317: static const uint survivor_index = 1; >> 318: static const uint num_inseparable_spaces = 2; > > One more comment. These should be CamelCase, and I have an idea to get rid of `num_inseparable_spaces`. > > If we make `_claimed_index` a signed integral type we could define `EdenIndex = -2` and `SurvivorIndex = -1`. If we then initialize `_claimed_index = EdenIndex` the old gen indices will be correct without needing a decrease. Good idea! I also suggest to rename _n_blocks to _max_iteratable_block_index in HeapBlockClaimer, To avoid incorrectly considering _n_blocks to be "total number of blocks to be iterated". ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From lzang at openjdk.java.net Mon Oct 26 03:20:37 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 26 Oct 2020 03:20:37 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v4] In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 03:09:57 GMT, Lin Zang wrote: >> src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 318: >> >>> 316: static const uint eden_index = 0; >>> 317: static const uint survivor_index = 1; >>> 318: static const uint num_inseparable_spaces = 2; >> >> One more comment. These should be CamelCase, and I have an idea to get rid of `num_inseparable_spaces`. >> >> If we make `_claimed_index` a signed integral type we could define `EdenIndex = -2` and `SurvivorIndex = -1`. If we then initialize `_claimed_index = EdenIndex` the old gen indices will be correct without needing a decrease. > > Good idea! I also suggest to rename _n_blocks to _max_iteratable_block_index in HeapBlockClaimer, To avoid incorrectly considering _n_blocks to be "total number of blocks to be iterated". Or the _n_blocks could be deleted, I will update the PR soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From lzang at openjdk.java.net Mon Oct 26 03:23:37 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 26 Oct 2020 03:23:37 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v4] In-Reply-To: <6yTg9zMAJ3rXyu8u5vtH7_Sah9EYWd0pXyaUqwhFBAQ=.64738637-681e-4dd9-9bfc-74d5c614892e@github.com> References: <6yTg9zMAJ3rXyu8u5vtH7_Sah9EYWd0pXyaUqwhFBAQ=.64738637-681e-4dd9-9bfc-74d5c614892e@github.com> Message-ID: On Thu, 22 Oct 2020 08:30:09 GMT, Stefan Johansson wrote: >> Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/hotspot/share/gc/parallel/psOldGen.cpp line 199: > >> 197: >> 198: // iterate objects in block. >> 199: HeapWord* end = MIN2(top, begin + _iterate_block_size); > > `_iterate_block_size` is a size in bytes (or at least you use it like a size in bytes when calculating the number of blocks), so before you can add it you need to convert it to a size in words like this: > > Suggestion: > > size_t block_word_size = _iterate_block_size / HeapWordSize; > HeapWord* begin = bottom + block_index * block_word_size; > > assert((block_word_size % (ObjectStartArray::block_size)) == 0, > "BLOCK SIZE not a multiple of start_array block"); > > // iterate objects in block. > HeapWord* end = MIN2(top, begin + block_word_size); Nice catch!, Paul mentioned it in previous review, I missed to update it. ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From ngasson at openjdk.java.net Mon Oct 26 05:59:53 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 26 Oct 2020 05:59:53 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v3] In-Reply-To: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: > When using the Linux "perf" tool to do system profiling, symbol names of > running Java methods cannot be decoded, resulting in unhelpful output > such as: > > 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 > > Perf can read a simple text file format describing the mapping between > address ranges and symbol names for a particular process [1]. > > It's possible to generate this already for Java processes using a JVMTI > plugin such as perf-map-agent [2]. However this requires compiling > third-party code and then loading the agent into your Java process. It > would be more convenient if Hotspot could write this file directly using > a diagnostic command. The information required is almost identical to > that of the existing Compiler.codelist command. > > This patch adds a Compiler.perfmap diagnostic command on Linux only. To > use, first run "jcmd Compiler.perfmap" and then "perf top" or > "perf record" and the report should show decoded Java symbol names for > that process. > > As this just writes a snapshot of the code cache when the command is > run, it will become stale if methods are compiled later or unloaded. > However this shouldn't be a big problem in practice if the map file is > generated after the application has warmed up. > > [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt > [2] https://github.com/jvm-profiling-tools/perf-map-agent Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: Add -XX:+DumpPerfMapAtExit option ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/760/files - new: https://git.openjdk.java.net/jdk/pull/760/files/a3cb0ed4..bd35433e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=760&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=760&range=01-02 Stats: 43 lines in 8 files changed: 29 ins; 7 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/760.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/760/head:pull/760 PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Mon Oct 26 06:06:47 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 26 Oct 2020 06:06:47 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v4] In-Reply-To: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: > When using the Linux "perf" tool to do system profiling, symbol names of > running Java methods cannot be decoded, resulting in unhelpful output > such as: > > 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 > > Perf can read a simple text file format describing the mapping between > address ranges and symbol names for a particular process [1]. > > It's possible to generate this already for Java processes using a JVMTI > plugin such as perf-map-agent [2]. However this requires compiling > third-party code and then loading the agent into your Java process. It > would be more convenient if Hotspot could write this file directly using > a diagnostic command. The information required is almost identical to > that of the existing Compiler.codelist command. > > This patch adds a Compiler.perfmap diagnostic command on Linux only. To > use, first run "jcmd Compiler.perfmap" and then "perf top" or > "perf record" and the report should show decoded Java symbol names for > that process. > > As this just writes a snapshot of the code cache when the command is > run, it will become stale if methods are compiled later or unloaded. > However this shouldn't be a big problem in practice if the map file is > generated after the application has warmed up. > > [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt > [2] https://github.com/jvm-profiling-tools/perf-map-agent Nick Gasson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge master - Add -XX:+DumpPerfMapAtExit option - Update for review comments - 8254723: add diagnostic command to write Linux perf map file When using the Linux "perf" tool to do system profiling, symbol names of running Java methods cannot be decoded, resulting in unhelpful output such as: 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 Perf can read a simple text file format describing the mapping between address ranges and symbol names for a particular process [1]. It's possible to generate this already for Java processes using a JVMTI plugin such as perf-map-agent [2]. However this requires compiling third-party code and then loading the agent into your Java process. It would be more convenient if Hotspot could write this file directly using a diagnostic command. The information required is almost identical to that of the existing Compiler.codelist command. This patch adds a Compiler.perfmap diagnostic command on Linux only. To use, first run "jcmd Compiler.perfmap" and then "perf top" or "perf record" and the report should show decoded Java symbol names for that process. As this just writes a snapshot of the code cache when the command is run, it will become stale if methods are compiled later or unloaded. However this shouldn't be a big problem in practice if the map file is generated after the application has warmed up. [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt [2] https://github.com/jvm-profiling-tools/perf-map-agent ------------- Changes: https://git.openjdk.java.net/jdk/pull/760/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=760&range=03 Stats: 171 lines in 8 files changed: 169 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/760.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/760/head:pull/760 PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Mon Oct 26 06:13:37 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 26 Oct 2020 06:13:37 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: <9jhaf18gTpZmpz8wfp7x0lhvRl4DUOQdfbox2DzcExs=.df72b0d4-b121-482e-a6eb-214f216ac359@github.com> On Thu, 22 Oct 2020 07:09:47 GMT, Nick Gasson wrote: >> Hi Nick, >> >> this is a very useful idea! I missed this in the past. >> >> Some remarks. I'll try to keep bikeshedding to a minimum since you already have enough input. Mostly ergonomics. >> >> 1) Like Alexey, I would really wish for an print-at-exit switch. The common naming seems to be xxxAtExit (so not, OnExit). "PrintXxx" seems to be printing stuff out to tty, "DumpXxxx" for writing separate files (e.g. CDS map). So I would name it DumpPerfMapAtExit. >> >> 2) Dumping to /tmp is unexpected for me, I would prefer if the default were dumping to the current directory. That seems to be the default for other files too (cds map, hs-err file etc). >> >> 3) Not necessary but nice would be a an option to specify location of the dump file. >> >> 4) I think it would be nice to have these switches always available, so real product switches. Which would require you to write up a small CSR but I still think it would make sense. >> >> Cheers, Thomas > >> >> 1. Like Alexey, I would really wish for an print-at-exit switch. The common naming seems to be xxxAtExit (so not, OnExit). "PrintXxx" seems to be printing stuff out to tty, "DumpXxxx" for writing separate files (e.g. CDS map). So I would name it DumpPerfMapAtExit. >> > > OK, makes sense. > >> 2. Dumping to /tmp is unexpected for me, I would prefer if the default were dumping to the current directory. That seems to be the default for other files too (cds map, hs-err file etc). >> >> 3. Not necessary but nice would be a an option to specify location of the dump file. >> > > The `/tmp/perf-.map` is hardcoded into perf though ([see here](https://github.com/torvalds/linux/blob/master/tools/perf/util/map.c#L155)), so I don't think it's useful for the user to be able to change the location. > > I think we should use this option carefully because nmethod might be unloaded. So we should use this with `-XX:-UseCodeCacheFlushing`. > Thanks for the information. `-XX:+DumpPerfMapAtExit` will turn on `UseCodeCacheFlushing` if it's set to default. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Mon Oct 26 06:13:40 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 26 Oct 2020 06:13:40 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 18:03:11 GMT, Chris Plummer wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for review comments > > src/hotspot/share/code/codeCache.cpp line 1582: > >> 1580: cb->is_compiled() ? cb->as_compiled_method()->method()->external_name() >> 1581: : cb->name(); >> 1582: fs.print_cr(INTPTR_FORMAT " " INTPTR_FORMAT " %s", > > Indentation isn't right. Do you mean how the arguments are lined up on the continuation line below? ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Mon Oct 26 06:13:40 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 26 Oct 2020 06:13:40 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: <6N1OsuF-33tLIIy8NWmngR9cLmqAV0ID8V7tiNMdT3c=.402f474c-060a-43f0-8fa6-783ead7de234@github.com> On Thu, 22 Oct 2020 02:06:25 GMT, Yasumasa Suenaga wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for review comments > > src/hotspot/share/code/codeCache.cpp line 1571: > >> 1569: if (!fs.is_open()) { >> 1570: log_warning(codecache)("Failed to create %s for perf map", fname); >> 1571: st->print_cr("Failed to create %s", fname); > > `st->print_cr()` is still needed? and also I've intended to replace all `print_cr()` to UL (L1587) It's gone now. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From dholmes at openjdk.java.net Mon Oct 26 06:56:34 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Oct 2020 06:56:34 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: <9jhaf18gTpZmpz8wfp7x0lhvRl4DUOQdfbox2DzcExs=.df72b0d4-b121-482e-a6eb-214f216ac359@github.com> References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> <9jhaf18gTpZmpz8wfp7x0lhvRl4DUOQdfbox2DzcExs=.df72b0d4-b121-482e-a6eb-214f216ac359@github.com> Message-ID: <59x5Z52HdbynvbP3_FMwcYb08tGhLghAB0P3W6ALgKI=.1f1f7d99-c54f-4788-9f0e-391fb995eebb@github.com> On Mon, 26 Oct 2020 06:10:52 GMT, Nick Gasson wrote: >>> >>> 1. Like Alexey, I would really wish for an print-at-exit switch. The common naming seems to be xxxAtExit (so not, OnExit). "PrintXxx" seems to be printing stuff out to tty, "DumpXxxx" for writing separate files (e.g. CDS map). So I would name it DumpPerfMapAtExit. >>> >> >> OK, makes sense. >> >>> 2. Dumping to /tmp is unexpected for me, I would prefer if the default were dumping to the current directory. That seems to be the default for other files too (cds map, hs-err file etc). >>> >>> 3. Not necessary but nice would be a an option to specify location of the dump file. >>> >> >> The `/tmp/perf-.map` is hardcoded into perf though ([see here](https://github.com/torvalds/linux/blob/master/tools/perf/util/map.c#L155)), so I don't think it's useful for the user to be able to change the location. > >> >> I think we should use this option carefully because nmethod might be unloaded. So we should use this with `-XX:-UseCodeCacheFlushing`. >> > > Thanks for the information. `-XX:+DumpPerfMapAtExit` will turn on `UseCodeCacheFlushing` if it's set to default. I don't see any reason for this to be a product flag, rather than diagnostic. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From lzang at openjdk.java.net Mon Oct 26 07:40:50 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 26 Oct 2020 07:40:50 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v5] In-Reply-To: References: Message-ID: > - Parallel heap iteration support for PSS > - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 Lin Zang has updated the pull request incrementally with one additional commit since the last revision: Refine HeapBlockClaimer implementation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/25/files - new: https://git.openjdk.java.net/jdk/pull/25/files/2878fc01..d1ca71d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=25&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=25&range=03-04 Stats: 75 lines in 4 files changed: 5 ins; 40 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/25/head:pull/25 PR: https://git.openjdk.java.net/jdk/pull/25 From lzang at openjdk.java.net Mon Oct 26 07:46:38 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 26 Oct 2020 07:46:38 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v4] In-Reply-To: <6yTg9zMAJ3rXyu8u5vtH7_Sah9EYWd0pXyaUqwhFBAQ=.64738637-681e-4dd9-9bfc-74d5c614892e@github.com> References: <6yTg9zMAJ3rXyu8u5vtH7_Sah9EYWd0pXyaUqwhFBAQ=.64738637-681e-4dd9-9bfc-74d5c614892e@github.com> Message-ID: On Thu, 22 Oct 2020 08:54:58 GMT, Stefan Johansson wrote: >> Lin Zang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > Took a second look today and found two additional problems. > > I would also be interested in what kind of testing you've done with this patch. Dear @kstefanj, I have made a new commit that refined the HeapBlockClaimer. Thanks a lot for your review! And I have conduced the following tests: (on x86_64 ubuntu system) * tier1 test with no regression * jmap -histo:parallel=[N] [pid] with N = 0,1,2,3,4, 10000, with a java thread running with "-XX:+UseParallelGC -XX:ParaelGCThreads=4" options. All test worked as expected (All test worked normally and "histo" data dumped are same) Thanks, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From sspitsyn at openjdk.java.net Mon Oct 26 18:30:21 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 26 Oct 2020 18:30:21 GMT Subject: RFR: 8252117: com/sun/jdi/BadHandshakeTest.java failed with "ConnectException: Connection refused: connect" [v2] In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 22:44:50 GMT, Alex Menkov wrote: >> Please review the fix for BadHandshakeTest. >> Summary: >> The test verifies that bad (testcase1) or incomplete (testcase2) handshake does not cause debuggee termination. >> To check this it tries to attach to the debuggee again (connect in testcase2 is also verification for testcase1) >> >> The fix adds reply logic to the last attach (similar to retry logic in testcase2) > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Fix the comment Hi Alex, It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/789 From sspitsyn at openjdk.java.net Tue Oct 27 00:55:21 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 27 Oct 2020 00:55:21 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3] In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 20:35:29 GMT, Richard Reingruber wrote: >> The following test cases try to provoke VMOutOfMemoryException during object reallocation because of JVMTI PopFrame / ForceEarlyReturn: >> >> EAPopFrameNotInlinedReallocFailure >> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure >> EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure >> >> For ZGC (so far) this is not 100% reliable. >> >> Just ignoring the runs where the expected OOME was not raised was not accepted. >> >> Summary of the now accepted solution: >> >> - The 3 problematic test cases are skipped if ZGC is selected. >> >> - They are also skipped if no OOME during object reallocation can be expected because allocations are not eliminated. >> >> - In consumeAllMemory, as a last step, empty LinkedList nodes are created without long array to fill up small blocks of free memory. >> >> - EATests.java is removed from the problem list for ZGC. > > Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Skip test cases expecting OOMEs if running with ZGC. > - Merge branch 'master' into JDK-8255072-eatests-oom-not-thrown > - Make OOME more reliable and skip test cases if it is not expected because scalar replacement is disabled > - 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown Hi Richard, It looks good to me. One nit: public static final boolean DoEscapeAnalysis = unbox(WB.getBooleanVMFlag("DoEscapeAnalysis"), UseJVMCICompiler); public static final boolean EliminateAllocations = unbox(WB.getBooleanVMFlag("EliminateAllocations"), UseJVMCICompiler); // read by debugger public static final boolean DeoptimizeObjectsALot = WB.getBooleanVMFlag("DeoptimizeObjectsALot"); // read by debugger public static final long BiasedLockingBulkRebiasThreshold = WB.getIntxVMFlag("BiasedLockingBulkRebiasThreshold"); public static final long BiasedLockingBulkRevokeThreshold = WB.getIntxVMFlag("BiasedLockingBulkRevokeThreshold"); + public static final boolean ZGCIsSelected = GC.Z.isSelected(); There are unneeded spaces before '=' sign. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/775 From sspitsyn at openjdk.java.net Tue Oct 27 01:09:23 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 27 Oct 2020 01:09:23 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v4] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Mon, 26 Oct 2020 06:06:47 GMT, Nick Gasson wrote: >> When using the Linux "perf" tool to do system profiling, symbol names of >> running Java methods cannot be decoded, resulting in unhelpful output >> such as: >> >> 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 >> >> Perf can read a simple text file format describing the mapping between >> address ranges and symbol names for a particular process [1]. >> >> It's possible to generate this already for Java processes using a JVMTI >> plugin such as perf-map-agent [2]. However this requires compiling >> third-party code and then loading the agent into your Java process. It >> would be more convenient if Hotspot could write this file directly using >> a diagnostic command. The information required is almost identical to >> that of the existing Compiler.codelist command. >> >> This patch adds a Compiler.perfmap diagnostic command on Linux only. To >> use, first run "jcmd Compiler.perfmap" and then "perf top" or >> "perf record" and the report should show decoded Java symbol names for >> that process. >> >> As this just writes a snapshot of the code cache when the command is >> run, it will become stale if methods are compiled later or unloaded. >> However this shouldn't be a big problem in practice if the map file is >> generated after the application has warmed up. >> >> [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt >> [2] https://github.com/jvm-profiling-tools/perf-map-agent > > Nick Gasson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge master > - Add -XX:+DumpPerfMapAtExit option > - Update for review comments > - 8254723: add diagnostic command to write Linux perf map file > > When using the Linux "perf" tool to do system profiling, symbol names of > running Java methods cannot be decoded, resulting in unhelpful output > such as: > > 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 > > Perf can read a simple text file format describing the mapping between > address ranges and symbol names for a particular process [1]. > > It's possible to generate this already for Java processes using a JVMTI > plugin such as perf-map-agent [2]. However this requires compiling > third-party code and then loading the agent into your Java process. It > would be more convenient if Hotspot could write this file directly using > a diagnostic command. The information required is almost identical to > that of the existing Compiler.codelist command. > > This patch adds a Compiler.perfmap diagnostic command on Linux only. To > use, first run "jcmd Compiler.perfmap" and then "perf top" or > "perf record" and the report should show decoded Java symbol names for > that process. > > As this just writes a snapshot of the code cache when the command is > run, it will become stale if methods are compiled later or unloaded. > However this shouldn't be a big problem in practice if the map file is > generated after the application has warmed up. > > [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt > [2] https://github.com/jvm-profiling-tools/perf-map-agent Hi Nick, This looks good. Thank you for the update. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Tue Oct 27 04:21:33 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 27 Oct 2020 04:21:33 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v5] In-Reply-To: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: <1IQqVGMwEJYYpHWOQXdtJvIp3hs6mjEJkaMfTb3lwWo=.5cb02e47-d773-41ba-b206-b2657417124c@github.com> > When using the Linux "perf" tool to do system profiling, symbol names of > running Java methods cannot be decoded, resulting in unhelpful output > such as: > > 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 > > Perf can read a simple text file format describing the mapping between > address ranges and symbol names for a particular process [1]. > > It's possible to generate this already for Java processes using a JVMTI > plugin such as perf-map-agent [2]. However this requires compiling > third-party code and then loading the agent into your Java process. It > would be more convenient if Hotspot could write this file directly using > a diagnostic command. The information required is almost identical to > that of the existing Compiler.codelist command. > > This patch adds a Compiler.perfmap diagnostic command on Linux only. To > use, first run "jcmd Compiler.perfmap" and then "perf top" or > "perf record" and the report should show decoded Java symbol names for > that process. > > As this just writes a snapshot of the code cache when the command is > run, it will become stale if methods are compiled later or unloaded. > However this shouldn't be a big problem in practice if the map file is > generated after the application has warmed up. > > [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt > [2] https://github.com/jvm-profiling-tools/perf-map-agent Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: Make DumpPerfMapAtExit a diagnostic option ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/760/files - new: https://git.openjdk.java.net/jdk/pull/760/files/959adca5..d8a399a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=760&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=760&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/760.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/760/head:pull/760 PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Tue Oct 27 04:21:36 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 27 Oct 2020 04:21:36 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v4] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Tue, 27 Oct 2020 01:07:04 GMT, Serguei Spitsyn wrote: >> Nick Gasson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Merge master >> - Add -XX:+DumpPerfMapAtExit option >> - Update for review comments >> - 8254723: add diagnostic command to write Linux perf map file >> >> When using the Linux "perf" tool to do system profiling, symbol names of >> running Java methods cannot be decoded, resulting in unhelpful output >> such as: >> >> 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 >> >> Perf can read a simple text file format describing the mapping between >> address ranges and symbol names for a particular process [1]. >> >> It's possible to generate this already for Java processes using a JVMTI >> plugin such as perf-map-agent [2]. However this requires compiling >> third-party code and then loading the agent into your Java process. It >> would be more convenient if Hotspot could write this file directly using >> a diagnostic command. The information required is almost identical to >> that of the existing Compiler.codelist command. >> >> This patch adds a Compiler.perfmap diagnostic command on Linux only. To >> use, first run "jcmd Compiler.perfmap" and then "perf top" or >> "perf record" and the report should show decoded Java symbol names for >> that process. >> >> As this just writes a snapshot of the code cache when the command is >> run, it will become stale if methods are compiled later or unloaded. >> However this shouldn't be a big problem in practice if the map file is >> generated after the application has warmed up. >> >> [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt >> [2] https://github.com/jvm-profiling-tools/perf-map-agent > > Hi Nick, > > This looks good. > Thank you for the update. > > Thanks, > Serguei > I don't see any reason for this to be a product flag, rather than diagnostic. OK sure, I've made it a diagnostic flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From rrich at openjdk.java.net Tue Oct 27 10:04:19 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 27 Oct 2020 10:04:19 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v3] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 00:52:20 GMT, Serguei Spitsyn wrote: >> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Skip test cases expecting OOMEs if running with ZGC. >> - Merge branch 'master' into JDK-8255072-eatests-oom-not-thrown >> - Make OOME more reliable and skip test cases if it is not expected because scalar replacement is disabled >> - 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown > > Hi Richard, > It looks good to me. > One nit: > public static final boolean DoEscapeAnalysis = unbox(WB.getBooleanVMFlag("DoEscapeAnalysis"), UseJVMCICompiler); > public static final boolean EliminateAllocations = unbox(WB.getBooleanVMFlag("EliminateAllocations"), UseJVMCICompiler); // read by debugger > public static final boolean DeoptimizeObjectsALot = WB.getBooleanVMFlag("DeoptimizeObjectsALot"); // read by debugger > public static final long BiasedLockingBulkRebiasThreshold = WB.getIntxVMFlag("BiasedLockingBulkRebiasThreshold"); > public static final long BiasedLockingBulkRevokeThreshold = WB.getIntxVMFlag("BiasedLockingBulkRevokeThreshold"); > + public static final boolean ZGCIsSelected = GC.Z.isSelected(); > There are unneeded spaces before '=' sign. > > Thanks, > Serguei Hi Serguei, thanks for reviewing. I'll remove the whitespace. I'm able now to reproduce the issue but only with ZGC. So far my attempts(*) to reliably get the OOME during ForceEarlyReturn/PopFrame because of object reallocation failed though. So I'm still in favour of the current solution which is: skip the 3 problematic testcases if ZGC is selected in the target vm. I'm still open for suggestions also though. I'll wait a few more days and then I'll integrate. Thanks, Richard. (*) I tried: - disable TLAB - call WhiteBox.fullGC() in consumeAllMemory() before the last round of allocations. - Check if the memory can be allocated by the thread doing the PopFrame/ForceEarlyReturn. com.sun.jdi.ThreadReference::invokeMethod() cannot be used. A target thread has to be specified and the jdwp threads are not visible through jdi. Only a dedicated native test JVMTI agent can consume all memory and then do the PopFrame/ForceEarlyReturn. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From rrich at openjdk.java.net Tue Oct 27 10:16:29 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 27 Oct 2020 10:16:29 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v4] In-Reply-To: References: Message-ID: > The following test cases try to provoke VMOutOfMemoryException during object reallocation because of JVMTI PopFrame / ForceEarlyReturn: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > For ZGC (so far) this is not 100% reliable. > > Just ignoring the runs where the expected OOME was not raised was not accepted. > > Summary of the now accepted solution: > > - The 3 problematic test cases are skipped if ZGC is selected. > > - They are also skipped if no OOME during object reallocation can be expected because allocations are not eliminated. > > - In consumeAllMemory, as a last step, empty LinkedList nodes are created without long array to fill up small blocks of free memory. > > - EATests.java is removed from the problem list for ZGC. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Whitespace/indentation clean-up. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/775/files - new: https://git.openjdk.java.net/jdk/pull/775/files/33ceb741..4676f1da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=02-03 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/775/head:pull/775 PR: https://git.openjdk.java.net/jdk/pull/775 From eosterlund at openjdk.java.net Tue Oct 27 13:31:36 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 27 Oct 2020 13:31:36 GMT Subject: RFR: 8255243: Reinforce escape barrier interactions with ZGC conc stack processing [v2] In-Reply-To: References: Message-ID: > The escape barrier reallocates scalarized objects potentially deep into the stack of a remote thread. Each allocation can safepoint, causing referenced frames to be invalid. Some sprinklings were added that deal with that, but I believe it was subsequently broken with the integration of the new vector API, that has its own new deoptimization code that did not know about this. Not surprisingly, the integration of the new vector API had no idea about this subtlety, and allocates an object, and then reads an object deep from the stack of a remote thread (using an escape barrier). I suppose the issue is that all these 3 things were integrated at almost the same time. The problematic code sequence is in VectorSupport::allocate_vector() in vectorSupport.cpp, which is called from Deoptimization::realloc_objects(). It first allocates an oop (possibly safepointing), and then reads a vector oop from the stack. This is usually fine, but not through the escape barrier, with concurrent stack sc anning. While I have not seen any crashes yet, I can see from code inspection, that there is no way that this works correctly. > > In order to make this less fragile for future changes, we should really have a RAII object that keeps the target thread's stack of the escape barrier, stable and processed, across safepoints. This patch fixes that. Then it becomes much easier to reason about its correctness, compared to hoping the various hooks are applied after each safepoint. > > With this new robustness fix, the thread running the escape barrier, keeps the target thread stack processed, straight through safepoints on the requesting thread, making it easy and intuitive to understand why this works correctly. The RAII object basically just has to cover the code block that pokes at the remote stack and goes in and out of safepoints, arbitrarily. Arguably, this escape barrier doesn't need to be blazingly fast, and can afford keeping stacks sane through its operation. Erik ?sterlund has updated the pull request incrementally with two additional commits since the last revision: - Better encapsulate object deoptimization in EscapeBarrier also to facilitate correct interaction with concurrent thread stack processing. The Stackwalk for object deoptimization in VM_GetOrSetLocal::doit_prologue is not prepared for concurrent thread stack processing. EscapeBarrier::deoptimize_objects(int depth) is extended to cover a range of frames from depth d1 to depth d2. It is also prepared for concurrent thread stack processing. With this change it is used to deoptimize objects in the prologue of VM_GetOrSetLocal. - Review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/832/files - new: https://git.openjdk.java.net/jdk/pull/832/files/5159c9a2..7db0bab1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=832&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=832&range=00-01 Stats: 120 lines in 9 files changed: 27 ins; 63 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/832.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/832/head:pull/832 PR: https://git.openjdk.java.net/jdk/pull/832 From eosterlund at openjdk.java.net Tue Oct 27 13:31:36 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 27 Oct 2020 13:31:36 GMT Subject: RFR: 8255243: Reinforce escape barrier interactions with ZGC conc stack processing [v2] In-Reply-To: References: <_J8bYqJcDa-5BvnEtZkdc3zIY21IfgEXTYvSSWy7znY=.074f43c7-ceac-4bb2-907e-b141d273dc4e@github.com> <5tKw_M8ud42YEtE-k_93YPjTbpC13BRPT20afBbInbA=.039581b3-7c53-42fa-947f-d672d2192202@github.com> Message-ID: <6a6IAyQBDlOUwyJ4qnxDc9BxK0zJYtMy5PRW33GFhcA=.a6661933-fcca-4700-9265-a4018f206e11@github.com> On Mon, 26 Oct 2020 15:19:51 GMT, Richard Reingruber wrote: >>> Hi Erik, the last commit in https://github.com/reinrich/jdk/commits/pr-832-with-better-encapsulation would be the refactoring I would like to do. It removes the code not compliant with concurrent thread stack processing from VM_GetOrSetLocal::doit_prologue(). Instead EscapeBarrier::deoptimize_objects(int d1, int d2) is called. You added already a KeepStackGCProcessedMark to that method and I changed it to accept a range [d1, d2] of frames do the object deoptimization for. >>> >>> I'm not sure how to handle this from a process point of view. Can the refactoring be done within this change? Should a new item or subtask be created for it. I'd be glad if you could give an advice on that. >>> >>> Thanks, Richard. >> >> If you are okay with it, I can add your refactorings into this change, and add you as a co-author of the change. Sounds good? >> >> Thanks, > > It does sound good indeed to me if you don't mind doing that. Thanks! > I have run the tests dedicated to EscapeBarriers with ZGC enabled and also the DeoptimizeObjectsALot stress testing. I will run some more serviceability tests and my teams CI testing until tomorrow. Thanks @reinrich. I uploaded your patch to this PR, and will add you as contributor. Also addressed your review comments. Hope your testing went fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/832 From rrich at openjdk.java.net Tue Oct 27 14:42:21 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 27 Oct 2020 14:42:21 GMT Subject: RFR: 8255243: Reinforce escape barrier interactions with ZGC conc stack processing [v2] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 13:31:36 GMT, Erik ?sterlund wrote: >> The escape barrier reallocates scalarized objects potentially deep into the stack of a remote thread. Each allocation can safepoint, causing referenced frames to be invalid. Some sprinklings were added that deal with that, but I believe it was subsequently broken with the integration of the new vector API, that has its own new deoptimization code that did not know about this. Not surprisingly, the integration of the new vector API had no idea about this subtlety, and allocates an object, and then reads an object deep from the stack of a remote thread (using an escape barrier). I suppose the issue is that all these 3 things were integrated at almost the same time. The problematic code sequence is in VectorSupport::allocate_vector() in vectorSupport.cpp, which is called from Deoptimization::realloc_objects(). It first allocates an oop (possibly safepointing), and then reads a vector oop from the stack. This is usually fine, but not through the escape barrier, with concurrent stack s canning. While I have not seen any crashes yet, I can see from code inspection, that there is no way that this works correctly. >> >> In order to make this less fragile for future changes, we should really have a RAII object that keeps the target thread's stack of the escape barrier, stable and processed, across safepoints. This patch fixes that. Then it becomes much easier to reason about its correctness, compared to hoping the various hooks are applied after each safepoint. >> >> With this new robustness fix, the thread running the escape barrier, keeps the target thread stack processed, straight through safepoints on the requesting thread, making it easy and intuitive to understand why this works correctly. The RAII object basically just has to cover the code block that pokes at the remote stack and goes in and out of safepoints, arbitrarily. Arguably, this escape barrier doesn't need to be blazingly fast, and can afford keeping stacks sane through its operation. > > Erik ?sterlund has updated the pull request incrementally with two additional commits since the last revision: > > - Better encapsulate object deoptimization in EscapeBarrier also to facilitate correct interaction with concurrent thread stack processing. > > The Stackwalk for object deoptimization in VM_GetOrSetLocal::doit_prologue is not prepared for concurrent thread stack processing. > EscapeBarrier::deoptimize_objects(int depth) is extended to cover a range of frames from depth d1 to depth d2. It is also prepared for concurrent thread stack processing. With this change it is used to deoptimize objects in the prologue of VM_GetOrSetLocal. > - Review comments Thanks for making EscapeBarriers more robust with regard to concurrent thread stack processing. The change looks good to me. ------------- Marked as reviewed by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/832 From rrich at openjdk.java.net Tue Oct 27 14:42:23 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 27 Oct 2020 14:42:23 GMT Subject: RFR: 8255243: Reinforce escape barrier interactions with ZGC conc stack processing [v2] In-Reply-To: <6a6IAyQBDlOUwyJ4qnxDc9BxK0zJYtMy5PRW33GFhcA=.a6661933-fcca-4700-9265-a4018f206e11@github.com> References: <_J8bYqJcDa-5BvnEtZkdc3zIY21IfgEXTYvSSWy7znY=.074f43c7-ceac-4bb2-907e-b141d273dc4e@github.com> <5tKw_M8ud42YEtE-k_93YPjTbpC13BRPT20afBbInbA=.039581b3-7c53-42fa-947f-d672d2192202@github.com> <6a6IAyQBDlOUwyJ4qnxDc9BxK0zJYtMy5PRW33GFhcA=.a6661933-fcca-4700-9265-a4018f206e11@github.com> Message-ID: On Tue, 27 Oct 2020 13:28:53 GMT, Erik ?sterlund wrote: >> It does sound good indeed to me if you don't mind doing that. Thanks! >> I have run the tests dedicated to EscapeBarriers with ZGC enabled and also the DeoptimizeObjectsALot stress testing. I will run some more serviceability tests and my teams CI testing until tomorrow. > > Thanks @reinrich. I uploaded your patch to this PR, and will add you as contributor. Also addressed your review comments. Hope your testing went fine. Thanks for importing the patch and for addressing my comments. I've tested hotspot_serviceability, jdk_svc, jdk_jdi, vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, vmTestbase_nsk_jdwp. Just the test jdk/jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java fails repeatedly with ZGC. It does so independently of this pr. ------------- PR: https://git.openjdk.java.net/jdk/pull/832 From redestad at openjdk.java.net Tue Oct 27 14:56:33 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 27 Oct 2020 14:56:33 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v2] In-Reply-To: References: Message-ID: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into threadHeapSampler_constexpr - Remove _log_table_initialized assert - Refactor ThreadHeapSampler::_log_table as constexpr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/2a66158a..f28b9cc4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=00-01 Stats: 1880 lines in 75 files changed: 1373 ins; 312 del; 195 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From xliu at openjdk.java.net Tue Oct 27 17:11:27 2020 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 27 Oct 2020 17:11:27 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: <-uWNzjVSMK3A2pbJURqukL7uAVMzr-oIs9PPMPP0Sw8=.7150d944-62ee-41c9-b234-b2a52ae331c9@github.com> On Wed, 21 Oct 2020 09:13:08 GMT, Nick Gasson wrote: >> When using the Linux "perf" tool to do system profiling, symbol names of >> running Java methods cannot be decoded, resulting in unhelpful output >> such as: >> >> 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 >> >> Perf can read a simple text file format describing the mapping between >> address ranges and symbol names for a particular process [1]. >> >> It's possible to generate this already for Java processes using a JVMTI >> plugin such as perf-map-agent [2]. However this requires compiling >> third-party code and then loading the agent into your Java process. It >> would be more convenient if Hotspot could write this file directly using >> a diagnostic command. The information required is almost identical to >> that of the existing Compiler.codelist command. >> >> This patch adds a Compiler.perfmap diagnostic command on Linux only. To >> use, first run "jcmd Compiler.perfmap" and then "perf top" or >> "perf record" and the report should show decoded Java symbol names for >> that process. >> >> As this just writes a snapshot of the code cache when the command is >> run, it will become stale if methods are compiled later or unloaded. >> However this shouldn't be a big problem in practice if the map file is >> generated after the application has warmed up. >> >> [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt >> [2] https://github.com/jvm-profiling-tools/perf-map-agent > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Update for review comments src/hotspot/share/code/codeCache.cpp line 1566: > 1564: > 1565: char fname[32]; > 1566: jio_snprintf(fname, sizeof(fname), "/tmp/perf-%d.map", os::current_process_id()); if you don't use #ifdef LINUX, this line needs a cross-platform temp. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From xliu at openjdk.java.net Tue Oct 27 17:26:21 2020 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 27 Oct 2020 17:26:21 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: <-uWNzjVSMK3A2pbJURqukL7uAVMzr-oIs9PPMPP0Sw8=.7150d944-62ee-41c9-b234-b2a52ae331c9@github.com> References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> <-uWNzjVSMK3A2pbJURqukL7uAVMzr-oIs9PPMPP0Sw8=.7150d944-62ee-41c9-b234-b2a52ae331c9@github.com> Message-ID: On Tue, 27 Oct 2020 17:08:18 GMT, Xin Liu wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for review comments > > src/hotspot/share/code/codeCache.cpp line 1566: > >> 1564: >> 1565: char fname[32]; >> 1566: jio_snprintf(fname, sizeof(fname), "/tmp/perf-%d.map", os::current_process_id()); > > if you don't use #ifdef LINUX, this line needs a cross-platform temp. I would like to take back this. I've seen that `CodeCache::write_perf_map` is wrapped by #ifdef LINUX. I read the older revision of change. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From sgehwolf at openjdk.java.net Tue Oct 27 19:06:19 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 27 Oct 2020 19:06:19 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: On Mon, 12 Oct 2020 13:24:16 GMT, Severin Gehwolf wrote: > Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). > > When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. > > Thoughts? @bobvandette Could you please take a look at this when you get a chance? I'd like to get this in before I propose [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) which would enable us to have better tests for all sorts of corner cases irrespective of the system it runs on. ------------- PR: https://git.openjdk.java.net/jdk/pull/609 From amenkov at openjdk.java.net Tue Oct 27 19:57:17 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 27 Oct 2020 19:57:17 GMT Subject: Integrated: 8252117: com/sun/jdi/BadHandshakeTest.java failed with "ConnectException: Connection refused: connect" In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 00:00:17 GMT, Alex Menkov wrote: > Please review the fix for BadHandshakeTest. > Summary: > The test verifies that bad (testcase1) or incomplete (testcase2) handshake does not cause debuggee termination. > To check this it tries to attach to the debuggee again (connect in testcase2 is also verification for testcase1) > > The fix adds reply logic to the last attach (similar to retry logic in testcase2) This pull request has now been integrated. Changeset: 1d245c6e Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/1d245c6e Stats: 45 lines in 1 file changed: 28 ins; 5 del; 12 mod 8252117: com/sun/jdi/BadHandshakeTest.java failed with "ConnectException: Connection refused: connect" Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/789 From iklam at openjdk.java.net Tue Oct 27 23:11:20 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 27 Oct 2020 23:11:20 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v2] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 14:56:33 GMT, Claes Redestad wrote: >> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. >> >> I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: >> >> [5.428s][debug][heapsampling] log2, 0.0751173 secs >> [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs >> [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs >> >> I've verified that this refactoring does not affect performance in this naive setup. >> >> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into threadHeapSampler_constexpr > - Remove _log_table_initialized assert > - Refactor ThreadHeapSampler::_log_table as constexpr Changes requested by iklam (Reviewer). src/hotspot/share/runtime/threadHeapSampler.cpp line 48: > 46: }; > 47: > 48: const FastLogTable ThreadHeapSampler::_log_table; To guarantee that `_log_table` is evaluated at C++ compile time, it's best to change the code to constexpr FastLogTable _log_table; There are 2 reasons: 1. C++ guarantees compile-time evaluation only if the expression is used in a "constexpr context". You can read more from [here](https://isocpp.org/blog/2013/01/when-does-a-constexpr-function-get-evaluated-at-compile-time-stackoverflow). 2. In the future, if the `FastLogTable` constructor is modified in a way that cannot be evaluated at compile time, (e.g., someone removes `constexpr` from the constructor's declaration by mistake, the C++ compiler will catch that and tell you that `_log_table` cannot be `constexpr`. Unfortunately, you cannot use `constexpr` in forward declarations, so you should either move the definition of `FastLogTable` to the hpp file, or remove the declaration of `_log_table` from the hpp file. ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From ngasson at openjdk.java.net Wed Oct 28 02:13:17 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 28 Oct 2020 02:13:17 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v4] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Tue, 27 Oct 2020 04:17:34 GMT, Nick Gasson wrote: >> Hi Nick, >> >> This looks good. >> Thank you for the update. >> >> Thanks, >> Serguei > >> I don't see any reason for this to be a product flag, rather than diagnostic. > > OK sure, I've made it a diagnostic flag. > @nick-arm only [Reviewers](https://openjdk.java.net/bylaws#reviewer) can determine that a CSR is not needed. @dholmes-ora would you mind helping to remove the csr label? I don't have permission to do it. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From shade at openjdk.java.net Wed Oct 28 09:54:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 28 Oct 2020 09:54:20 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code [v3] In-Reply-To: <5Jk_4mxRk_8rIaxUY9NhUNhOmjdIuRuV-KWzeSrLkaI=.07c9a141-6335-4e52-8aff-3fcbfce02a17@github.com> References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> <5Jk_4mxRk_8rIaxUY9NhUNhOmjdIuRuV-KWzeSrLkaI=.07c9a141-6335-4e52-8aff-3fcbfce02a17@github.com> Message-ID: On Fri, 23 Oct 2020 15:51:47 GMT, Severin Gehwolf wrote: >> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). >> >> When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. >> >> Thoughts? > > Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. This looks okay to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/609 From sjohanss at openjdk.java.net Wed Oct 28 11:04:26 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 28 Oct 2020 11:04:26 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v5] In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 07:40:50 GMT, Lin Zang wrote: >> - Parallel heap iteration support for PSS >> - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > Refine HeapBlockClaimer implementation Thanks for the update, some additional comments, but just minor things. I did some basic local testing and I've also started some tests to build on multiple platforms, once the review is complete I will do a more thorough test run to make sure the code is exercised on all platforms as well. src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 588: > 586: return new PSScavengeParallelObjectIterator(thread_num); > 587: } > 588: No need to pass down thread_num to `PSScavengeParallelObjectIterator` because it is not needed anymore. This way we can also remove the `_thread_num` member. src/hotspot/share/gc/parallel/psOldGen.hpp line 56: > 54: > 55: // Block size for parallel iteration > 56: static const size_t _iterate_block_size = 1024 * 1024; Constants are named without _ and using camel case. I think you can also add to the comment that the size is in bytes: Suggestion: // Block size in bytes for parallel iteration static const size_t IterateBlockSize = 1024 * 1024; Also remember to update the comments referring to the constant :) src/hotspot/share/gc/parallel/psOldGen.hpp line 169: > 167: void object_iterate(ObjectClosure* cl) { object_space()->object_iterate(cl); } > 168: uint iterable_blocks() { > 169: return (object_space()->used_in_bytes() + _iterate_block_size -1) / _iterate_block_size; Space before 1 in `-1`. ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/25 From lzang at openjdk.java.net Wed Oct 28 11:31:01 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 28 Oct 2020 11:31:01 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v6] In-Reply-To: References: Message-ID: <7A6PxJ4yyuBIe39g76H4KEalu0AF41cbOrhLpxJhRd8=.255a631b-4d83-49ba-93c7-fb2c2a9f047d@github.com> > - Parallel heap iteration support for PSS > - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 Lin Zang has updated the pull request incrementally with one additional commit since the last revision: fix constant coding style and do code refine ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/25/files - new: https://git.openjdk.java.net/jdk/pull/25/files/d1ca71d8..2d432f95 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=25&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=25&range=04-05 Stats: 8 lines in 3 files changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/25/head:pull/25 PR: https://git.openjdk.java.net/jdk/pull/25 From lzang at openjdk.java.net Wed Oct 28 11:31:02 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 28 Oct 2020 11:31:02 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v5] In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 11:00:32 GMT, Stefan Johansson wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> Refine HeapBlockClaimer implementation > > Thanks for the update, some additional comments, but just minor things. > > I did some basic local testing and I've also started some tests to build on multiple platforms, once the review is complete I will do a more thorough test run to make sure the code is exercised on all platforms as well. Hi @kstefanj Thanks again for your review. I updated a new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/25 From sjohanss at openjdk.java.net Wed Oct 28 13:14:47 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 28 Oct 2020 13:14:47 GMT Subject: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap [v6] In-Reply-To: <7A6PxJ4yyuBIe39g76H4KEalu0AF41cbOrhLpxJhRd8=.255a631b-4d83-49ba-93c7-fb2c2a9f047d@github.com> References: <7A6PxJ4yyuBIe39g76H4KEalu0AF41cbOrhLpxJhRd8=.255a631b-4d83-49ba-93c7-fb2c2a9f047d@github.com> Message-ID: <5nwwZOJTU_p-bm5OmzJphw-JAN2_EBjobNe5_Ao7Xu8=.84bca5a7-a513-4580-908b-e21072669817@github.com> On Wed, 28 Oct 2020 11:31:01 GMT, Lin Zang wrote: >> - Parallel heap iteration support for PSS >> - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > fix constant coding style and do code refine The build testing caught an error. If you enable GitHub actions for openjdk, you will get basic testing like this automatically (if your branch is based on a recent master or merged recently). src/hotspot/share/gc/parallel/psOldGen.hpp line 170: > 168: uint iterable_blocks() { > 169: return (object_space()->used_in_bytes() + IterateBlockSize - 1) / IterateBlockSize; > 170: } This causes a build failure on windows: hotspot\share\gc/parallel/psOldGen.hpp(169): error C2220: the following warning is treated as an error hotspot\share\gc/parallel/psOldGen.hpp(169): warning C4267: 'return': conversion from 'size_t' to 'uint', possible loss of data I suggest either changing the return here to `int` and make an explicit cast or `size_t` and then add the cast when used in `claim_and_get_block()` ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/25 From sgehwolf at openjdk.java.net Wed Oct 28 13:49:53 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 28 Oct 2020 13:49:53 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code [v4] In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: > Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). > > When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. > > Thoughts? Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8253939: [TESTBUG] Increase coverage of the cgroups detection code ------------- Changes: https://git.openjdk.java.net/jdk/pull/609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=03 Stats: 147 lines in 2 files changed: 134 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/609/head:pull/609 PR: https://git.openjdk.java.net/jdk/pull/609 From redestad at openjdk.java.net Wed Oct 28 14:11:04 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Oct 2020 14:11:04 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v3] In-Reply-To: References: Message-ID: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp - Merge branch 'master' into threadHeapSampler_constexpr - Merge branch 'master' into threadHeapSampler_constexpr - Remove _log_table_initialized assert - Refactor ThreadHeapSampler::_log_table as constexpr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/f28b9cc4..62148744 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=01-02 Stats: 922 lines in 50 files changed: 556 ins; 221 del; 145 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Wed Oct 28 14:18:51 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Oct 2020 14:18:51 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v2] In-Reply-To: References: Message-ID: <38r92xz8Q0CM1q6V0YFmrO739eO3mz0ZLNSo0wU6_So=.b6155b44-0468-479e-8a89-a6b770f719a9@github.com> On Tue, 27 Oct 2020 23:08:13 GMT, Ioi Lam wrote: >> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Remove _log_table_initialized assert >> - Refactor ThreadHeapSampler::_log_table as constexpr > > src/hotspot/share/runtime/threadHeapSampler.cpp line 48: > >> 46: }; >> 47: >> 48: const FastLogTable ThreadHeapSampler::_log_table; > > To guarantee that `_log_table` is evaluated at C++ compile time, it's best to change the code to > > constexpr FastLogTable _log_table; > > There are 2 reasons: > > 1. C++ guarantees compile-time evaluation only if the expression is used in a "constexpr context". You can read more from [here](https://isocpp.org/blog/2013/01/when-does-a-constexpr-function-get-evaluated-at-compile-time-stackoverflow). > 2. In the future, if the `FastLogTable` constructor is modified in a way that cannot be evaluated at compile time, (e.g., someone removes `constexpr` from the constructor's declaration by mistake, the C++ compiler will catch that and tell you that `_log_table` cannot be `constexpr`. > > Unfortunately, you cannot use `constexpr` in forward declarations, so you should either move the definition of `FastLogTable` to the hpp file, or remove the declaration of `_log_table` from the hpp file. Ok, makes sense. I went with removing the `_log_table` declaration from the hpp file. I think things came out a bit cleaner as a result, too. ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Wed Oct 28 14:36:59 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Oct 2020 14:36:59 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v4] In-Reply-To: References: Message-ID: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into threadHeapSampler_constexpr - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp - Merge branch 'master' into threadHeapSampler_constexpr - Merge branch 'master' into threadHeapSampler_constexpr - Remove _log_table_initialized assert - Refactor ThreadHeapSampler::_log_table as constexpr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/62148744..f796147d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=02-03 Stats: 364 lines in 32 files changed: 294 ins; 21 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Wed Oct 28 15:36:46 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Oct 2020 15:36:46 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v2] In-Reply-To: References: Message-ID: <4nmtA7n_BrVDrnFAa0ytD4iKBjYTxhTRPtPGV4agWnU=.c44fa156-775b-4d19-948d-efcede4969a0@github.com> On Tue, 27 Oct 2020 23:08:21 GMT, Ioi Lam wrote: >> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Remove _log_table_initialized assert >> - Refactor ThreadHeapSampler::_log_table as constexpr > > Changes requested by iklam (Reviewer). The change to declare the log_table as constexpr exposed an issue with the std `log` function not being constexpr, which now cause a build error on Windows and Mac. It works on Linux, but likely not robustly so since I seem to have been stumbling into a non-compliant quirk: https://stackoverflow.com/questions/50477974/constexpr-exp-log-pow ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From bobv at openjdk.java.net Wed Oct 28 15:45:52 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Wed, 28 Oct 2020 15:45:52 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code [v4] In-Reply-To: References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: On Wed, 28 Oct 2020 13:49:53 GMT, Severin Gehwolf wrote: >> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). >> >> When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. >> >> Thoughts? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: > > 8253939: [TESTBUG] Increase coverage of the cgroups detection code Looks good. ------------- Marked as reviewed by bobv (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/609 From sgehwolf at openjdk.java.net Wed Oct 28 17:19:52 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 28 Oct 2020 17:19:52 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code [v4] In-Reply-To: References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: On Wed, 28 Oct 2020 15:42:37 GMT, Bob Vandette wrote: >> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: >> >> 8253939: [TESTBUG] Increase coverage of the cgroups detection code > > Looks good. Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/609 From sgehwolf at openjdk.java.net Wed Oct 28 18:57:46 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 28 Oct 2020 18:57:46 GMT Subject: Integrated: 8253939: [TESTBUG] Increase coverage of the cgroups detection code In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: On Mon, 12 Oct 2020 13:24:16 GMT, Severin Gehwolf wrote: > Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). > > When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. > > Thoughts? This pull request has now been integrated. Changeset: 42fc1589 Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/42fc1589 Stats: 147 lines in 2 files changed: 134 ins; 0 del; 13 mod 8253939: [TESTBUG] Increase coverage of the cgroups detection code Reviewed-by: shade, bobv ------------- PR: https://git.openjdk.java.net/jdk/pull/609 From sspitsyn at openjdk.java.net Wed Oct 28 19:47:47 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 28 Oct 2020 19:47:47 GMT Subject: RFR: 8255243: Reinforce escape barrier interactions with ZGC conc stack processing [v2] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 13:31:36 GMT, Erik ?sterlund wrote: >> The escape barrier reallocates scalarized objects potentially deep into the stack of a remote thread. Each allocation can safepoint, causing referenced frames to be invalid. Some sprinklings were added that deal with that, but I believe it was subsequently broken with the integration of the new vector API, that has its own new deoptimization code that did not know about this. Not surprisingly, the integration of the new vector API had no idea about this subtlety, and allocates an object, and then reads an object deep from the stack of a remote thread (using an escape barrier). I suppose the issue is that all these 3 things were integrated at almost the same time. The problematic code sequence is in VectorSupport::allocate_vector() in vectorSupport.cpp, which is called from Deoptimization::realloc_objects(). It first allocates an oop (possibly safepointing), and then reads a vector oop from the stack. This is usually fine, but not through the escape barrier, with concurrent stack s canning. While I have not seen any crashes yet, I can see from code inspection, that there is no way that this works correctly. >> >> In order to make this less fragile for future changes, we should really have a RAII object that keeps the target thread's stack of the escape barrier, stable and processed, across safepoints. This patch fixes that. Then it becomes much easier to reason about its correctness, compared to hoping the various hooks are applied after each safepoint. >> >> With this new robustness fix, the thread running the escape barrier, keeps the target thread stack processed, straight through safepoints on the requesting thread, making it easy and intuitive to understand why this works correctly. The RAII object basically just has to cover the code block that pokes at the remote stack and goes in and out of safepoints, arbitrarily. Arguably, this escape barrier doesn't need to be blazingly fast, and can afford keeping stacks sane through its operation. > > Erik ?sterlund has updated the pull request incrementally with two additional commits since the last revision: > > - Better encapsulate object deoptimization in EscapeBarrier also to facilitate correct interaction with concurrent thread stack processing. > > The Stackwalk for object deoptimization in VM_GetOrSetLocal::doit_prologue is not prepared for concurrent thread stack processing. > EscapeBarrier::deoptimize_objects(int depth) is extended to cover a range of frames from depth d1 to depth d2. It is also prepared for concurrent thread stack processing. With this change it is used to deoptimize objects in the prologue of VM_GetOrSetLocal. > - Review comments Hi Erik and Richard, Changes in the serviceability files looks fine. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/832 From sspitsyn at openjdk.java.net Wed Oct 28 20:00:55 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 28 Oct 2020 20:00:55 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v4] In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 14:36:59 GMT, Claes Redestad wrote: >> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. >> >> I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: >> >> [5.428s][debug][heapsampling] log2, 0.0751173 secs >> [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs >> [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs >> >> I've verified that this refactoring does not affect performance in this naive setup. >> >> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into threadHeapSampler_constexpr > - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp > - Merge branch 'master' into threadHeapSampler_constexpr > - Merge branch 'master' into threadHeapSampler_constexpr > - Remove _log_table_initialized assert > - Refactor ThreadHeapSampler::_log_table as constexpr Hi Ioi and Claes, This looks nice. One nit: + _values[i] = (log(1.0 + static_cast(i+0.5) / N) / log(2.0)); Need spaces around '+' sign. Also, it can be just one line. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/880 From kvn at openjdk.java.net Wed Oct 28 20:15:46 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 28 Oct 2020 20:15:46 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v4] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 10:16:29 GMT, Richard Reingruber wrote: >> The following test cases try to provoke VMOutOfMemoryException during object reallocation because of JVMTI PopFrame / ForceEarlyReturn: >> >> EAPopFrameNotInlinedReallocFailure >> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure >> EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure >> >> For ZGC (so far) this is not 100% reliable. >> >> Just ignoring the runs where the expected OOME was not raised was not accepted. >> >> Summary of the now accepted solution: >> >> - The 3 problematic test cases are skipped if ZGC is selected. >> >> - They are also skipped if no OOME during object reallocation can be expected because allocations are not eliminated. >> >> - In consumeAllMemory, as a last step, empty LinkedList nodes are created without long array to fill up small blocks of free memory. >> >> - EATests.java is removed from the problem list for ZGC. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Whitespace/indentation clean-up. Please change @requires for testing with Graal to `vm.graal.enabled` instead of `vm.jvmci` ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/775 From eosterlund at openjdk.java.net Wed Oct 28 21:39:44 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 28 Oct 2020 21:39:44 GMT Subject: RFR: 8255243: Reinforce escape barrier interactions with ZGC conc stack processing [v2] In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 19:44:33 GMT, Serguei Spitsyn wrote: > Hi Erik and Richard, > > Changes in the serviceability files looks fine. > > Thanks, > > Serguei > > Thanks for the review Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/832 From lzang at openjdk.java.net Thu Oct 29 08:58:44 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 29 Oct 2020 08:58:44 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 14:00:34 GMT, Claes Redestad wrote: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Dear @cl4es, I am not a reviewer, just have 1 comment that maybe you need to update the Year info in the headers of touched files. Thanks. Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From eosterlund at openjdk.java.net Thu Oct 29 12:51:48 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 29 Oct 2020 12:51:48 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop Message-ID: The imasm::remove_activation() call does not deal with safepoints very well. However, when the MethodExit JVMTI event is being called, we call into the runtime in the middle of remove_activation(). If the value being returned is an object type, then the top-of-stack contains the oop. However, the GC does not traverse said oop in any oop map, because it is simply not expected that we safepoint in the middle of remove_activation(). The JvmtiExport::post_method_exit() function we end up calling, reads the top-of-stack oop, and puts it in a handle. Then it calls JVMTI callbacks, that eventually call Java and a bunch of stuff that safepoints. So after the JVMTI callback, we can expect the top-of-stack oop to be broken. Unfortunately, when we continue, we therefore end up returning a broken oop. Notably, the fact that InterpreterRuntime::post_method_exit is a JRT_ENTRY, is wrong, as we can safepoint on the way back to Java, which will break the return oop in a similar way. So this patch makes it a JRT_BLOCK_ENTRY, moving the transition to VM and back, into a block of code that is protected against GC. Before the JRT_BLOCK is called, we stash away the return oop, and after the JRT_BLOCK_END, we restore the top-of-stack oop. In the path when InterpreterRuntime::post_method_exit is called when throwing an exception, we don't have the same problem of retaining an oop result, and hence the JRT_BLOCK/JRT_BLOCK_END section is not performed in this case; the logic is the same as before for this path. This is a JVMTI bug that has probably been around for a long time. It crashes with all GCs, but was discovered recently after concurrent stack processing, as StefanK has been running better GC stressing code in JVMTI, and the bug reproduced more easily with concurrent stack processing, as the timings were a bit different. The following reproducer failed pretty much 100% of the time: while true; do make test JTREG="RETAIN=all" TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue003/returnValue003.java TEST_OPTS_JAVA_OPTIONS="-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=0.0001 -XX:ZFragmentationLimit=0.01 -XX:+VerifyOops -XX:+ZVerifyViews -Xint" ; done With my fix I can run this repeatedly without any more failures. I have also sanity checked the patch by running tier 1-5, so that it does not introduces any new issues on its own. I have also used Stefan's nice external GC stressing with jcmd technique that was used to trigger crashes with other GCs, to make sure said crashes no longer reproduce either. ------------- Commit messages: - 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop Changes: https://git.openjdk.java.net/jdk/pull/930/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=930&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255452 Stats: 46 lines in 3 files changed: 39 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/930.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/930/head:pull/930 PR: https://git.openjdk.java.net/jdk/pull/930 From redestad at openjdk.java.net Thu Oct 29 14:03:56 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 29 Oct 2020 14:03:56 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v5] In-Reply-To: References: Message-ID: <26xqj78f6sfo9CXjlQAZRTdSeRe0nSU8rnzb1Sb8gJo=.36a30bf2-99e8-46c1-8bae-7efa35cfc989@github.com> > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Desugar constexpr into code generator and output ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/f796147d..61bac3dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=03-04 Stats: 292 lines in 2 files changed: 281 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Thu Oct 29 14:14:46 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 29 Oct 2020 14:14:46 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 08:56:13 GMT, Lin Zang wrote: >> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. >> >> I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: >> >> [5.428s][debug][heapsampling] log2, 0.0751173 secs >> [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs >> [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs >> >> I've verified that this refactoring does not affect performance in this naive setup. >> >> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 > > Dear @cl4es, > I am not a reviewer, just have 1 comment that maybe you need to update the Year info in the headers of touched files. > > Thanks. > Lin Unfortunately there's currently no portable way to use `std::log` (or any of the other `std` math functions) in a constexpr, so I had to resort to a code generator approach instead. It's either that or withdrawing this PR. Using UL and a debug-only block to implement an adhoc code generator (`-Xlog:heapsampling+generate::none`) might be a bit unorthodox, but I think it turned out OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Thu Oct 29 14:23:04 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 29 Oct 2020 14:23:04 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v6] In-Reply-To: References: Message-ID: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: - Add explicit include of logging - Add const, fix copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/61bac3dc..a802814f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=04-05 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From eosterlund at openjdk.java.net Thu Oct 29 14:22:56 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 29 Oct 2020 14:22:56 GMT Subject: Integrated: 8255243: Reinforce escape barrier interactions with ZGC conc stack processing In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 10:25:43 GMT, Erik ?sterlund wrote: > The escape barrier reallocates scalarized objects potentially deep into the stack of a remote thread. Each allocation can safepoint, causing referenced frames to be invalid. Some sprinklings were added that deal with that, but I believe it was subsequently broken with the integration of the new vector API, that has its own new deoptimization code that did not know about this. Not surprisingly, the integration of the new vector API had no idea about this subtlety, and allocates an object, and then reads an object deep from the stack of a remote thread (using an escape barrier). I suppose the issue is that all these 3 things were integrated at almost the same time. The problematic code sequence is in VectorSupport::allocate_vector() in vectorSupport.cpp, which is called from Deoptimization::realloc_objects(). It first allocates an oop (possibly safepointing), and then reads a vector oop from the stack. This is usually fine, but not through the escape barrier, with concurrent stack sc anning. While I have not seen any crashes yet, I can see from code inspection, that there is no way that this works correctly. > > In order to make this less fragile for future changes, we should really have a RAII object that keeps the target thread's stack of the escape barrier, stable and processed, across safepoints. This patch fixes that. Then it becomes much easier to reason about its correctness, compared to hoping the various hooks are applied after each safepoint. > > With this new robustness fix, the thread running the escape barrier, keeps the target thread stack processed, straight through safepoints on the requesting thread, making it easy and intuitive to understand why this works correctly. The RAII object basically just has to cover the code block that pokes at the remote stack and goes in and out of safepoints, arbitrarily. Arguably, this escape barrier doesn't need to be blazingly fast, and can afford keeping stacks sane through its operation. This pull request has now been integrated. Changeset: 5b185585 Author: Erik ?sterlund URL: https://git.openjdk.java.net/jdk/commit/5b185585 Stats: 268 lines in 15 files changed: 164 ins; 72 del; 32 mod 8255243: Reinforce escape barrier interactions with ZGC conc stack processing Co-authored-by: Richard Reingruber Reviewed-by: rrich, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/832 From rrich at openjdk.java.net Thu Oct 29 14:53:54 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 29 Oct 2020 14:53:54 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v4] In-Reply-To: References: Message-ID: <4RqPScJJcCjXJM4JafcdYZsiitxLeLpi5lfcEN4afrg=.088a9144-9413-4654-b76a-0c5b37530952@github.com> On Wed, 28 Oct 2020 20:13:15 GMT, Vladimir Kozlov wrote: > > > Please change @requires for testing with Graal to `vm.graal.enabled` instead of `vm.jvmci` Sure. I've done that now. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From rrich at openjdk.java.net Thu Oct 29 14:53:54 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 29 Oct 2020 14:53:54 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v5] In-Reply-To: References: Message-ID: > The following test cases try to provoke VMOutOfMemoryException during object reallocation because of JVMTI PopFrame / ForceEarlyReturn: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > For ZGC (so far) this is not 100% reliable. > > Just ignoring the runs where the expected OOME was not raised was not accepted. > > Summary of the now accepted solution: > > - The 3 problematic test cases are skipped if ZGC is selected. > > - They are also skipped if no OOME during object reallocation can be expected because allocations are not eliminated. > > - In consumeAllMemory, as a last step, empty LinkedList nodes are created without long array to fill up small blocks of free memory. > > - EATests.java is removed from the problem list for ZGC. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Replaced vm.jvmci with vm.graal.enabled in @requires clause. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/775/files - new: https://git.openjdk.java.net/jdk/pull/775/files/4676f1da..4e878e8e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/775/head:pull/775 PR: https://git.openjdk.java.net/jdk/pull/775 From kvn at openjdk.java.net Thu Oct 29 15:37:43 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 29 Oct 2020 15:37:43 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v5] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 14:53:54 GMT, Richard Reingruber wrote: >> The following test cases try to provoke VMOutOfMemoryException during object reallocation because of JVMTI PopFrame / ForceEarlyReturn: >> >> EAPopFrameNotInlinedReallocFailure >> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure >> EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure >> >> For ZGC (so far) this is not 100% reliable. >> >> Just ignoring the runs where the expected OOME was not raised was not accepted. >> >> Summary of the now accepted solution: >> >> - The 3 problematic test cases are skipped if ZGC is selected. >> >> - They are also skipped if no OOME during object reallocation can be expected because allocations are not eliminated. >> >> - In consumeAllMemory, as a last step, empty LinkedList nodes are created without long array to fill up small blocks of free memory. >> >> - EATests.java is removed from the problem list for ZGC. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Replaced vm.jvmci with vm.graal.enabled in @requires clause. Good ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/775 From iklam at openjdk.java.net Thu Oct 29 20:06:49 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 29 Oct 2020 20:06:49 GMT Subject: RFR: 8255455: Pre-generate ThreadHeapSampler::_log_table [v6] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 14:23:04 GMT, Claes Redestad wrote: >> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. >> >> I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: >> >> [5.428s][debug][heapsampling] log2, 0.0751173 secs >> [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs >> [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs >> >> I've verified that this refactoring does not affect performance in this naive setup. >> >> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - Add explicit include of logging > - Add const, fix copyright Marked as reviewed by iklam (Reviewer). src/hotspot/share/runtime/threadHeapSampler.cpp line 353: > 351: const uint32_t y = x_high >> (20 - FastLogNumBits) & FastLogMask; > 352: const int32_t exponent = ((x_high >> 20) & 0x7FF) - 1023; > 353: return exponent + log_table[y]; The pre-generated values look good to me. Just a small nit. You can decide whether to take this or not: C++ will generate an error if you have too many elements in `log_table[FastLogCount] = { ...`, but won't complain if you have not enough elements. Any uninitialized elements will take up the default value of 0. To prevent cut-and-paste errors in the future, I would suggest adding something like assert(FastLogCount > 0 && log_table[FastLogCount-1] != 0, "table should be full"); ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From coleenp at openjdk.java.net Thu Oct 29 21:25:45 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 29 Oct 2020 21:25:45 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 12:44:58 GMT, Erik ?sterlund wrote: > The imasm::remove_activation() call does not deal with safepoints very well. However, when the MethodExit JVMTI event is being called, we call into the runtime in the middle of remove_activation(). If the value being returned is an object type, then the top-of-stack contains the oop. However, the GC does not traverse said oop in any oop map, because it is simply not expected that we safepoint in the middle of remove_activation(). > > The JvmtiExport::post_method_exit() function we end up calling, reads the top-of-stack oop, and puts it in a handle. Then it calls JVMTI callbacks, that eventually call Java and a bunch of stuff that safepoints. So after the JVMTI callback, we can expect the top-of-stack oop to be broken. Unfortunately, when we continue, we therefore end up returning a broken oop. > > Notably, the fact that InterpreterRuntime::post_method_exit is a JRT_ENTRY, is wrong, as we can safepoint on the way back to Java, which will break the return oop in a similar way. So this patch makes it a JRT_BLOCK_ENTRY, moving the transition to VM and back, into a block of code that is protected against GC. Before the JRT_BLOCK is called, we stash away the return oop, and after the JRT_BLOCK_END, we restore the top-of-stack oop. In the path when InterpreterRuntime::post_method_exit is called when throwing an exception, we don't have the same problem of retaining an oop result, and hence the JRT_BLOCK/JRT_BLOCK_END section is not performed in this case; the logic is the same as before for this path. > > This is a JVMTI bug that has probably been around for a long time. It crashes with all GCs, but was discovered recently after concurrent stack processing, as StefanK has been running better GC stressing code in JVMTI, and the bug reproduced more easily with concurrent stack processing, as the timings were a bit different. The following reproducer failed pretty much 100% of the time: > while true; do make test JTREG="RETAIN=all" TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue003/returnValue003.java TEST_OPTS_JAVA_OPTIONS="-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=0.0001 -XX:ZFragmentationLimit=0.01 -XX:+VerifyOops -XX:+ZVerifyViews -Xint" ; done > > With my fix I can run this repeatedly without any more failures. I have also sanity checked the patch by running tier 1-5, so that it does not introduces any new issues on its own. I have also used Stefan's nice external GC stressing with jcmd technique that was used to trigger crashes with other GCs, to make sure said crashes no longer reproduce either. Changes requested by coleenp (Reviewer). src/hotspot/share/prims/jvmtiExport.cpp line 1600: > 1598: > 1599: if (exception_exit) { > 1600: post_method_exit_inner(thread, mh, state, exception_exit, current_frame, result, value); I think for exception exit, you also need JRT_BLOCK because you want the transition to thread_in_VM for this code, since JRT_BLOCK_ENTRY doesn't do the transition. It should be safe for exception exit and retain the old behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From eosterlund at openjdk.java.net Thu Oct 29 22:37:54 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 29 Oct 2020 22:37:54 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 21:23:12 GMT, Coleen Phillimore wrote: >> The imasm::remove_activation() call does not deal with safepoints very well. However, when the MethodExit JVMTI event is being called, we call into the runtime in the middle of remove_activation(). If the value being returned is an object type, then the top-of-stack contains the oop. However, the GC does not traverse said oop in any oop map, because it is simply not expected that we safepoint in the middle of remove_activation(). >> >> The JvmtiExport::post_method_exit() function we end up calling, reads the top-of-stack oop, and puts it in a handle. Then it calls JVMTI callbacks, that eventually call Java and a bunch of stuff that safepoints. So after the JVMTI callback, we can expect the top-of-stack oop to be broken. Unfortunately, when we continue, we therefore end up returning a broken oop. >> >> Notably, the fact that InterpreterRuntime::post_method_exit is a JRT_ENTRY, is wrong, as we can safepoint on the way back to Java, which will break the return oop in a similar way. So this patch makes it a JRT_BLOCK_ENTRY, moving the transition to VM and back, into a block of code that is protected against GC. Before the JRT_BLOCK is called, we stash away the return oop, and after the JRT_BLOCK_END, we restore the top-of-stack oop. In the path when InterpreterRuntime::post_method_exit is called when throwing an exception, we don't have the same problem of retaining an oop result, and hence the JRT_BLOCK/JRT_BLOCK_END section is not performed in this case; the logic is the same as before for this path. >> >> This is a JVMTI bug that has probably been around for a long time. It crashes with all GCs, but was discovered recently after concurrent stack processing, as StefanK has been running better GC stressing code in JVMTI, and the bug reproduced more easily with concurrent stack processing, as the timings were a bit different. The following reproducer failed pretty much 100% of the time: >> while true; do make test JTREG="RETAIN=all" TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue003/returnValue003.java TEST_OPTS_JAVA_OPTIONS="-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=0.0001 -XX:ZFragmentationLimit=0.01 -XX:+VerifyOops -XX:+ZVerifyViews -Xint" ; done >> >> With my fix I can run this repeatedly without any more failures. I have also sanity checked the patch by running tier 1-5, so that it does not introduces any new issues on its own. I have also used Stefan's nice external GC stressing with jcmd technique that was used to trigger crashes with other GCs, to make sure said crashes no longer reproduce either. > > src/hotspot/share/prims/jvmtiExport.cpp line 1600: > >> 1598: >> 1599: if (exception_exit) { >> 1600: post_method_exit_inner(thread, mh, state, exception_exit, current_frame, result, value); > > I think for exception exit, you also need JRT_BLOCK because you want the transition to thread_in_VM for this code, since JRT_BLOCK_ENTRY doesn't do the transition. It should be safe for exception exit and retain the old behavior. Thanks for having a look coleen. In fact, not doing the JRT_BLOCK for the exception entry is intentional, because that entry goes through a different JRT_ENTRY (not JRT_BLOCK_ENTRY), that already transitions. So if I do the JRT_BLOCK for the exception path, it asserts saying hey you are already in VM. ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From ngasson at openjdk.java.net Fri Oct 30 02:29:45 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 30 Oct 2020 02:29:45 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v5] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 04:35:14 GMT, Yasumasa Suenaga wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Make DumpPerfMapAtExit a diagnostic option > > Changes requested by ysuenaga (Reviewer). @YaSuenag could you re-review the latest changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ysuenaga at openjdk.java.net Fri Oct 30 04:36:45 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 30 Oct 2020 04:36:45 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v5] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 04:35:14 GMT, Yasumasa Suenaga wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Make DumpPerfMapAtExit a diagnostic option > > Changes requested by ysuenaga (Reviewer). > @YaSuenag could you re-review the latest changes? Sure, the change looks good to me. However I don't understand why CSR is not needed. It introduces new dcmd for Linux. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From rrich at openjdk.java.net Fri Oct 30 06:58:48 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 30 Oct 2020 06:58:48 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 21:23:21 GMT, Coleen Phillimore wrote: >> The imasm::remove_activation() call does not deal with safepoints very well. However, when the MethodExit JVMTI event is being called, we call into the runtime in the middle of remove_activation(). If the value being returned is an object type, then the top-of-stack contains the oop. However, the GC does not traverse said oop in any oop map, because it is simply not expected that we safepoint in the middle of remove_activation(). >> >> The JvmtiExport::post_method_exit() function we end up calling, reads the top-of-stack oop, and puts it in a handle. Then it calls JVMTI callbacks, that eventually call Java and a bunch of stuff that safepoints. So after the JVMTI callback, we can expect the top-of-stack oop to be broken. Unfortunately, when we continue, we therefore end up returning a broken oop. >> >> Notably, the fact that InterpreterRuntime::post_method_exit is a JRT_ENTRY, is wrong, as we can safepoint on the way back to Java, which will break the return oop in a similar way. So this patch makes it a JRT_BLOCK_ENTRY, moving the transition to VM and back, into a block of code that is protected against GC. Before the JRT_BLOCK is called, we stash away the return oop, and after the JRT_BLOCK_END, we restore the top-of-stack oop. In the path when InterpreterRuntime::post_method_exit is called when throwing an exception, we don't have the same problem of retaining an oop result, and hence the JRT_BLOCK/JRT_BLOCK_END section is not performed in this case; the logic is the same as before for this path. >> >> This is a JVMTI bug that has probably been around for a long time. It crashes with all GCs, but was discovered recently after concurrent stack processing, as StefanK has been running better GC stressing code in JVMTI, and the bug reproduced more easily with concurrent stack processing, as the timings were a bit different. The following reproducer failed pretty much 100% of the time: >> while true; do make test JTREG="RETAIN=all" TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue003/returnValue003.java TEST_OPTS_JAVA_OPTIONS="-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=0.0001 -XX:ZFragmentationLimit=0.01 -XX:+VerifyOops -XX:+ZVerifyViews -Xint" ; done >> >> With my fix I can run this repeatedly without any more failures. I have also sanity checked the patch by running tier 1-5, so that it does not introduces any new issues on its own. I have also used Stefan's nice external GC stressing with jcmd technique that was used to trigger crashes with other GCs, to make sure said crashes no longer reproduce either. > > Changes requested by coleenp (Reviewer). Hi Erik, is it possible for GC to mistake a primitive value for a reference when posting the exit event? My understanding is: we are at a random bci of a method that is forced to return early. The expression stack is emptied and the return value is pushed on the expression stack then we call into the interpreter runtime to post the JVMTI method exit event during which we come to a safepoint for GC. The oop map for the bci does not cover this forced early return and if the return value is an object then the reference pushed on the expression stack before is not updated by GC. With your fix the value is updated if it is a reference. If this is correct then to me it appears as if GC can also crash because the oop map for the random bci tells there has to be a reference at the stack position of the return value if it actually is a primitive value. ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From dlong at openjdk.java.net Fri Oct 30 08:06:42 2020 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 30 Oct 2020 08:06:42 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 06:56:13 GMT, Richard Reingruber wrote: >> Changes requested by coleenp (Reviewer). > > Hi Erik, > > is it possible for GC to mistake a primitive value for a reference when posting the exit event? > > My understanding is: we are at a random bci of a method that is forced to return early. The expression stack is emptied and the return value is pushed on the expression stack then we call into the interpreter runtime to post the JVMTI method exit event during which we come to a safepoint for GC. The oop map for the bci does not cover this forced early return and if the return value is an object then the reference pushed on the expression stack before is not updated by GC. With your fix the value is updated if it is a reference. > > If this is correct then to me it appears as if GC can also crash because the oop map for the random bci tells there has to be a reference at the stack position of the return value if it actually is a primitive value. I think you've discovered JDK-6449023. ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From dlong at openjdk.java.net Fri Oct 30 08:51:47 2020 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 30 Oct 2020 08:51:47 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 12:44:58 GMT, Erik ?sterlund wrote: > The imasm::remove_activation() call does not deal with safepoints very well. However, when the MethodExit JVMTI event is being called, we call into the runtime in the middle of remove_activation(). If the value being returned is an object type, then the top-of-stack contains the oop. However, the GC does not traverse said oop in any oop map, because it is simply not expected that we safepoint in the middle of remove_activation(). > > The JvmtiExport::post_method_exit() function we end up calling, reads the top-of-stack oop, and puts it in a handle. Then it calls JVMTI callbacks, that eventually call Java and a bunch of stuff that safepoints. So after the JVMTI callback, we can expect the top-of-stack oop to be broken. Unfortunately, when we continue, we therefore end up returning a broken oop. > > Notably, the fact that InterpreterRuntime::post_method_exit is a JRT_ENTRY, is wrong, as we can safepoint on the way back to Java, which will break the return oop in a similar way. So this patch makes it a JRT_BLOCK_ENTRY, moving the transition to VM and back, into a block of code that is protected against GC. Before the JRT_BLOCK is called, we stash away the return oop, and after the JRT_BLOCK_END, we restore the top-of-stack oop. In the path when InterpreterRuntime::post_method_exit is called when throwing an exception, we don't have the same problem of retaining an oop result, and hence the JRT_BLOCK/JRT_BLOCK_END section is not performed in this case; the logic is the same as before for this path. > > This is a JVMTI bug that has probably been around for a long time. It crashes with all GCs, but was discovered recently after concurrent stack processing, as StefanK has been running better GC stressing code in JVMTI, and the bug reproduced more easily with concurrent stack processing, as the timings were a bit different. The following reproducer failed pretty much 100% of the time: > while true; do make test JTREG="RETAIN=all" TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue003/returnValue003.java TEST_OPTS_JAVA_OPTIONS="-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=0.0001 -XX:ZFragmentationLimit=0.01 -XX:+VerifyOops -XX:+ZVerifyViews -Xint" ; done > > With my fix I can run this repeatedly without any more failures. I have also sanity checked the patch by running tier 1-5, so that it does not introduces any new issues on its own. I have also used Stefan's nice external GC stressing with jcmd technique that was used to trigger crashes with other GCs, to make sure said crashes no longer reproduce either. Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From rrich at openjdk.java.net Fri Oct 30 09:53:45 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 30 Oct 2020 09:53:45 GMT Subject: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v5] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 15:34:58 GMT, Vladimir Kozlov wrote: > Good Thanks for reviewing. Will integrate beginning of next week. ------------- PR: https://git.openjdk.java.net/jdk/pull/775 From coleenp at openjdk.java.net Fri Oct 30 12:33:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 30 Oct 2020 12:33:58 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 22:34:30 GMT, Erik ?sterlund wrote: >> src/hotspot/share/prims/jvmtiExport.cpp line 1600: >> >>> 1598: >>> 1599: if (exception_exit) { >>> 1600: post_method_exit_inner(thread, mh, state, exception_exit, current_frame, result, value); >> >> I think for exception exit, you also need JRT_BLOCK because you want the transition to thread_in_VM for this code, since JRT_BLOCK_ENTRY doesn't do the transition. It should be safe for exception exit and retain the old behavior. > > Thanks for having a look coleen. In fact, not doing the JRT_BLOCK for the exception entry is intentional, because that entry goes through a different JRT_ENTRY (not JRT_BLOCK_ENTRY), that already transitions. So if I do the JRT_BLOCK for the exception path, it asserts saying hey you are already in VM. Oh that's actually horrible. I wonder if it's possible to hoist saving the result oop into the InterpreterRuntime entry. And pass the Handle into JvmtiExport::post_method_exit(). ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From eosterlund at openjdk.java.net Fri Oct 30 14:12:57 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 30 Oct 2020 14:12:57 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 00:58:06 GMT, Coleen Phillimore wrote: >> Thanks for having a look coleen. In fact, not doing the JRT_BLOCK for the exception entry is intentional, because that entry goes through a different JRT_ENTRY (not JRT_BLOCK_ENTRY), that already transitions. So if I do the JRT_BLOCK for the exception path, it asserts saying hey you are already in VM. > > Oh that's actually horrible. I wonder if it's possible to hoist saving the result oop into the InterpreterRuntime entry. And pass the Handle into JvmtiExport::post_method_exit(). I tried that first, and ended up with a bunch of non-trivial code duplication instead, as reading the oop is done in both paths but for different reasons. One to preserve/restore it (interpreter remove_activation entry), but also inside of JvmtiExport::post_method_exit() so that it can be passed into the MethodExit. I will give it another shot and see if it is possible to refactor it in a better way. ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From eosterlund at openjdk.java.net Fri Oct 30 14:23:55 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 30 Oct 2020 14:23:55 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 08:49:08 GMT, Dean Long wrote: >> The imasm::remove_activation() call does not deal with safepoints very well. However, when the MethodExit JVMTI event is being called, we call into the runtime in the middle of remove_activation(). If the value being returned is an object type, then the top-of-stack contains the oop. However, the GC does not traverse said oop in any oop map, because it is simply not expected that we safepoint in the middle of remove_activation(). >> >> The JvmtiExport::post_method_exit() function we end up calling, reads the top-of-stack oop, and puts it in a handle. Then it calls JVMTI callbacks, that eventually call Java and a bunch of stuff that safepoints. So after the JVMTI callback, we can expect the top-of-stack oop to be broken. Unfortunately, when we continue, we therefore end up returning a broken oop. >> >> Notably, the fact that InterpreterRuntime::post_method_exit is a JRT_ENTRY, is wrong, as we can safepoint on the way back to Java, which will break the return oop in a similar way. So this patch makes it a JRT_BLOCK_ENTRY, moving the transition to VM and back, into a block of code that is protected against GC. Before the JRT_BLOCK is called, we stash away the return oop, and after the JRT_BLOCK_END, we restore the top-of-stack oop. In the path when InterpreterRuntime::post_method_exit is called when throwing an exception, we don't have the same problem of retaining an oop result, and hence the JRT_BLOCK/JRT_BLOCK_END section is not performed in this case; the logic is the same as before for this path. >> >> This is a JVMTI bug that has probably been around for a long time. It crashes with all GCs, but was discovered recently after concurrent stack processing, as StefanK has been running better GC stressing code in JVMTI, and the bug reproduced more easily with concurrent stack processing, as the timings were a bit different. The following reproducer failed pretty much 100% of the time: >> while true; do make test JTREG="RETAIN=all" TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue003/returnValue003.java TEST_OPTS_JAVA_OPTIONS="-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=0.0001 -XX:ZFragmentationLimit=0.01 -XX:+VerifyOops -XX:+ZVerifyViews -Xint" ; done >> >> With my fix I can run this repeatedly without any more failures. I have also sanity checked the patch by running tier 1-5, so that it does not introduces any new issues on its own. I have also used Stefan's nice external GC stressing with jcmd technique that was used to trigger crashes with other GCs, to make sure said crashes no longer reproduce either. > > Marked as reviewed by dlong (Reviewer). > I think you've discovered JDK-6449023. And you fix looks like the workaround I tried: > https://bugs.openjdk.java.net/browse/JDK-6449023?focusedCommentId=14206078&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14206078 Oh wow. I had no idea people have been having issues with this since 2009! Thanks for the pointer. Well, let's hope we can finally close it now after marinating the bug for 11 years. ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From redestad at openjdk.java.net Fri Oct 30 15:24:17 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 30 Oct 2020 15:24:17 GMT Subject: RFR: 8255455: Pre-generate ThreadHeapSampler::_log_table [v7] In-Reply-To: References: Message-ID: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' into threadHeapSampler_constexpr - Check log_table on startup in debug builds - Add explicit include of logging - Add const, fix copyright - Desugar constexpr into code generator and output - Merge branch 'master' into threadHeapSampler_constexpr - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp - Merge branch 'master' into threadHeapSampler_constexpr - Merge branch 'master' into threadHeapSampler_constexpr - Remove _log_table_initialized assert - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b5bd0028...0eebe57c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/a802814f..0eebe57c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=05-06 Stats: 11692 lines in 331 files changed: 6229 ins; 3920 del; 1543 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Fri Oct 30 15:27:58 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 30 Oct 2020 15:27:58 GMT Subject: RFR: 8255455: Pre-generate ThreadHeapSampler::_log_table [v6] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 20:04:11 GMT, Ioi Lam wrote: >> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add explicit include of logging >> - Add const, fix copyright > > Marked as reviewed by iklam (Reviewer). @iklam: I added a runtime verification pass that the values in the log_table are reasonably accurate. This adds around 100k instructions on startup on a debug build, which is in the noise there (currently hello world takes 470M on fastdebug builds). The checking is disabled in a code gen run to not put up tripwires when resizing the table. ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From eosterlund at openjdk.java.net Fri Oct 30 16:05:55 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 30 Oct 2020 16:05:55 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 14:20:42 GMT, Erik ?sterlund wrote: >> Marked as reviewed by dlong (Reviewer). > >> I think you've discovered JDK-6449023. And you fix looks like the workaround I tried: >> https://bugs.openjdk.java.net/browse/JDK-6449023?focusedCommentId=14206078&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14206078 > > Oh wow. I had no idea people have been having issues with this since 2009! Thanks for the pointer. Well, let's hope we can finally close it now after marinating the bug for 11 years. > Hi Erik, > > is it possible for GC to mistake a primitive value for a reference when posting the exit event? > > My understanding is: we are at a random bci of a method that is forced to return early. The expression stack is emptied and the return value is pushed on the expression stack then we call into the interpreter runtime to post the JVMTI method exit event during which we come to a safepoint for GC. The oop map for the bci does not cover this forced early return and if the return value is an object then the reference pushed on the expression stack before is not updated by GC. With your fix the value is updated if it is a reference. > > If this is correct then to me it appears as if GC can also crash because the oop map for the random bci tells there has to be a reference at the stack position of the return value if it actually is a primitive value. I think what you are saying is true. Note though that the return value of ForceEarlyReturn is installed with a handshake. The handshake polls of the interpreter are emitted in loop backedges and returns. At loop backedges, the expression stack is empty (required by OSR), and at returns the types match correctly. However, if an arbitrary bytecode performs a runtime call with call_VM() while the bottom of the expression stack is an oop, then I think there is an issue. At that call_VM, the early return value could get installed, and when the C++ function returns, we check for early returns, further dispatching to an unwind routine that posts the MethodExit notification. If we GC during this MethodExit notification, then I think you can crash the GC. The GC code generates an oop map for the frame, checking what the types in the expression stack should be. The early return int is pushed on the slot intersecting with the bottom entry in the expression stack. That bottom entry could be an o op, and the early return value could be an int. Then the early return int will be passed to the oop closure, which should result in a crash. So I suspect that almost always, the handshake installing the ForceEarlyReturn value is installed with a handshake in a bytecode backedge or at a return, where the interpreter safepoint polls for the fast path code. Then you won't notice the issue. But in the rare scenario that the ForceEarlyReturn value is installed in a slow path call from a random bytecode... I can't see how that would work correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From eosterlund at openjdk.java.net Fri Oct 30 16:40:53 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 30 Oct 2020 16:40:53 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 16:02:41 GMT, Erik ?sterlund wrote: > > Hi Erik, > > is it possible for GC to mistake a primitive value for a reference when posting the exit event? > > My understanding is: we are at a random bci of a method that is forced to return early. The expression stack is emptied and the return value is pushed on the expression stack then we call into the interpreter runtime to post the JVMTI method exit event during which we come to a safepoint for GC. The oop map for the bci does not cover this forced early return and if the return value is an object then the reference pushed on the expression stack before is not updated by GC. With your fix the value is updated if it is a reference. > > If this is correct then to me it appears as if GC can also crash because the oop map for the random bci tells there has to be a reference at the stack position of the return value if it actually is a primitive value. > > I think what you are saying is true. Note though that the return value of ForceEarlyReturn is installed with a handshake. The handshake polls of the interpreter are emitted in loop backedges and returns. At loop backedges, the expression stack is empty (required by OSR), and at returns the types match correctly. However, if an arbitrary bytecode performs a runtime call with call_VM() while the bottom of the expression stack is an oop, then I think there is an issue. At that call_VM, the early return value could get installed, and when the C++ function returns, we check for early returns, further dispatching to an unwind routine that posts the MethodExit notification. If we GC during this MethodExit notification, then I think you can crash the GC. The GC code generates an oop map for the frame, checking what the types in the expression stack should be. The early return int is pushed on the slot intersecting with the bottom entry in the expression stack. That bottom entry could be an oop, and the early return value could be an int. Then the early return int will be passed to the oop closure, which should result in a crash. > > So I suspect that almost always, the handshake installing the ForceEarlyReturn value is installed with a handshake in a bytecode backedge or at a return, where the interpreter safepoint polls for the fast path code. Then you won't notice the issue. But in the rare scenario that the ForceEarlyReturn value is installed in a slow path call from a random bytecode... I can't see how that would work correctly. Looking more closely, I gotta say I have no idea why there is a call to clear the expression stack at all in TemplateInterpreterGenerator::generate_earlyret_entry_for(). It is unclear to me what problem if any that solves. It does however seem like it introduces this problem of having a forced int return value intersect with an oop in the expression stack for a BCI performing slow-path calls into the VM. Simply removing the code that clears the expression stack, removes the issue, and I can't see that it introduces any other issue. Anyway, I think this is a separate bug. Do you mind if I push the fix for that bug, as a different RFR? It will likely involve poking around at more platform dependent code. ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From iklam at openjdk.java.net Fri Oct 30 17:42:01 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 30 Oct 2020 17:42:01 GMT Subject: RFR: 8255455: Pre-generate ThreadHeapSampler::_log_table [v7] In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 15:24:17 GMT, Claes Redestad wrote: >> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. >> >> I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: >> >> [5.428s][debug][heapsampling] log2, 0.0751173 secs >> [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs >> [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs >> >> I've verified that this refactoring does not affect performance in this naive setup. >> >> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into threadHeapSampler_constexpr > - Check log_table on startup in debug builds > - Add explicit include of logging > - Add const, fix copyright > - Desugar constexpr into code generator and output > - Merge branch 'master' into threadHeapSampler_constexpr > - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp > - Merge branch 'master' into threadHeapSampler_constexpr > - Merge branch 'master' into threadHeapSampler_constexpr > - Remove _log_table_initialized assert > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/63c0fc2d...0eebe57c LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/880 From kvn at openjdk.java.net Fri Oct 30 17:47:06 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 30 Oct 2020 17:47:06 GMT Subject: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK Message-ID: We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an experimental feature. We shipped Graal as an experimental JIT compiler in JDK 10. We haven't seen much use of these features, and the effort required to support and enhance them is significant. We therefore intend to disable these features in Oracle builds as of JDK 16. We'll leave the sources for these features in the repository, in case any one else is interested in building them. But we will not update or test them. We'll continue to build and ship JVMCI as an experimental feature in Oracle builds. Tested changes in all tiers. I verified that with these changes I still able to build Graal in open repo and run graalunit testing: `open$ bash test/hotspot/jtreg/compiler/graalunit/downloadLibs.sh /mydir/graalunit_lib/` `open$ bash configure --with-debug-level=fastdebug --with-graalunit-lib=/mydir/graalunit_lib/ --with-jtreg=/mydir/jtreg` `open$ make jdk-image` `open$ make test-image` `open$ make run-test TEST=compiler/graalunit/HotspotTest.java` ------------- Commit messages: - 8255616: Disable AOT and Graal in Oracle OpenJDK Changes: https://git.openjdk.java.net/jdk/pull/960/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=960&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255616 Stats: 36 lines in 4 files changed: 21 ins; 11 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/960.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/960/head:pull/960 PR: https://git.openjdk.java.net/jdk/pull/960 From iignatyev at openjdk.java.net Fri Oct 30 17:54:57 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 30 Oct 2020 17:54:57 GMT Subject: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 17:40:51 GMT, Vladimir Kozlov wrote: > We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an experimental feature. We shipped Graal as an experimental JIT compiler in JDK 10. We haven't seen much use of these features, and the effort required to support and enhance them is significant. We therefore intend to disable these features in Oracle builds as of JDK 16. > > We'll leave the sources for these features in the repository, in case any one else is interested in building them. But we will not update or test them. > > We'll continue to build and ship JVMCI as an experimental feature in Oracle builds. > > Tested changes in all tiers. > > I verified that with these changes I still able to build Graal in open repo and run graalunit testing: > > `open$ bash test/hotspot/jtreg/compiler/graalunit/downloadLibs.sh /mydir/graalunit_lib/` > `open$ bash configure --with-debug-level=fastdebug --with-graalunit-lib=/mydir/graalunit_lib/ --with-jtreg=/mydir/jtreg` > `open$ make jdk-image` > `open$ make test-image` > `open$ make run-test TEST=compiler/graalunit/HotspotTest.java` LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/960 From epavlova at openjdk.java.net Fri Oct 30 18:03:54 2020 From: epavlova at openjdk.java.net (Ekaterina Pavlova) Date: Fri, 30 Oct 2020 18:03:54 GMT Subject: RFR: 8255616: Disable AOT and Graal in Oracle OpenJDK In-Reply-To: References: Message-ID: <4hKiJTtog9q4y4x7hxaHMWUFdtjzrJe73i8Sys0Ukyg=.a1fdde60-fc8d-476b-9487-c796a668856f@github.com> On Fri, 30 Oct 2020 17:52:09 GMT, Igor Ignatyev wrote: >> We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an experimental feature. We shipped Graal as an experimental JIT compiler in JDK 10. We haven't seen much use of these features, and the effort required to support and enhance them is significant. We therefore intend to disable these features in Oracle builds as of JDK 16. >> >> We'll leave the sources for these features in the repository, in case any one else is interested in building them. But we will not update or test them. >> >> We'll continue to build and ship JVMCI as an experimental feature in Oracle builds. >> >> Tested changes in all tiers. >> >> I verified that with these changes I still able to build Graal in open repo and run graalunit testing: >> >> `open$ bash test/hotspot/jtreg/compiler/graalunit/downloadLibs.sh /mydir/graalunit_lib/` >> `open$ bash configure --with-debug-level=fastdebug --with-graalunit-lib=/mydir/graalunit_lib/ --with-jtreg=/mydir/jtreg` >> `open$ make jdk-image` >> `open$ make test-image` >> `open$ make run-test TEST=compiler/graalunit/HotspotTest.java` > > LGTM Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/960 From redestad at openjdk.java.net Fri Oct 30 18:18:58 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 30 Oct 2020 18:18:58 GMT Subject: RFR: 8255455: Pre-generate ThreadHeapSampler::_log_table [v7] In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 17:39:05 GMT, Ioi Lam wrote: >> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Check log_table on startup in debug builds >> - Add explicit include of logging >> - Add const, fix copyright >> - Desugar constexpr into code generator and output >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Remove _log_table_initialized assert >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/7a199d94...0eebe57c > > LGTM @iklam: thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Fri Oct 30 18:18:59 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 30 Oct 2020 18:18:59 GMT Subject: Integrated: 8255455: Pre-generate ThreadHeapSampler::_log_table In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 14:00:34 GMT, Claes Redestad wrote: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 This pull request has now been integrated. Changeset: 4158567f Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/4158567f Stats: 317 lines in 3 files changed: 296 ins; 10 del; 11 mod 8255455: Pre-generate ThreadHeapSampler::_log_table Reviewed-by: iklam, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From rrich at openjdk.java.net Fri Oct 30 18:40:56 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 30 Oct 2020 18:40:56 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 16:38:40 GMT, Erik ?sterlund wrote: > I think what you are saying is true. Note though that the return value of > ForceEarlyReturn is installed with a handshake. The handshake polls of the > interpreter are emitted in loop backedges and returns Yes right, I wasn't really aware of this. The thread has to be suspended though before the forced return (with a vm operation). > I gotta say I have no idea why there is a call to clear the expression stack > at all in TemplateInterpreterGenerator::generate_earlyret_entry_for(). It is > unclear to me what problem if any that solves. Don't really know either. Only thing I currently can think of is that the expression stack could overflow, not on x86 though. > Anyway, I think this is a separate bug. Do you mind if I push the fix for that > bug, as a different RFR? Not at all. > It will likely involve poking around at more platform dependent code. Likely. Another solution might be to delay loading the return value until the activation is removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From rrich at openjdk.java.net Fri Oct 30 18:43:57 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 30 Oct 2020 18:43:57 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: <2LEXltEp4CX8xzC9-Bufoe0vhsFqwduh6H6R9z2sCqs=.0f8443c1-b2d0-4451-8dfe-f081360b96d2@github.com> On Thu, 29 Oct 2020 12:44:58 GMT, Erik ?sterlund wrote: > The imasm::remove_activation() call does not deal with safepoints very well. However, when the MethodExit JVMTI event is being called, we call into the runtime in the middle of remove_activation(). If the value being returned is an object type, then the top-of-stack contains the oop. However, the GC does not traverse said oop in any oop map, because it is simply not expected that we safepoint in the middle of remove_activation(). > > The JvmtiExport::post_method_exit() function we end up calling, reads the top-of-stack oop, and puts it in a handle. Then it calls JVMTI callbacks, that eventually call Java and a bunch of stuff that safepoints. So after the JVMTI callback, we can expect the top-of-stack oop to be broken. Unfortunately, when we continue, we therefore end up returning a broken oop. > > Notably, the fact that InterpreterRuntime::post_method_exit is a JRT_ENTRY, is wrong, as we can safepoint on the way back to Java, which will break the return oop in a similar way. So this patch makes it a JRT_BLOCK_ENTRY, moving the transition to VM and back, into a block of code that is protected against GC. Before the JRT_BLOCK is called, we stash away the return oop, and after the JRT_BLOCK_END, we restore the top-of-stack oop. In the path when InterpreterRuntime::post_method_exit is called when throwing an exception, we don't have the same problem of retaining an oop result, and hence the JRT_BLOCK/JRT_BLOCK_END section is not performed in this case; the logic is the same as before for this path. > > This is a JVMTI bug that has probably been around for a long time. It crashes with all GCs, but was discovered recently after concurrent stack processing, as StefanK has been running better GC stressing code in JVMTI, and the bug reproduced more easily with concurrent stack processing, as the timings were a bit different. The following reproducer failed pretty much 100% of the time: > while true; do make test JTREG="RETAIN=all" TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue003/returnValue003.java TEST_OPTS_JAVA_OPTIONS="-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=0.0001 -XX:ZFragmentationLimit=0.01 -XX:+VerifyOops -XX:+ZVerifyViews -Xint" ; done > > With my fix I can run this repeatedly without any more failures. I have also sanity checked the patch by running tier 1-5, so that it does not introduces any new issues on its own. I have also used Stefan's nice external GC stressing with jcmd technique that was used to trigger crashes with other GCs, to make sure said crashes no longer reproduce either. Marked as reviewed by rrich (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/930 From coleenp at openjdk.java.net Fri Oct 30 20:31:10 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 30 Oct 2020 20:31:10 GMT Subject: RFR: 8212879: Make JVMTI TagMap table not hash on oop address Message-ID: This change turns the HashTable that JVMTI uses for object tagging into a regular Hotspot hashtable - the one in hashtable.hpp with resizing and rehashing. Instead of pointing directly to oops so that GC has to walk the table to follow oops and then to rehash the table, this table points to WeakHandle. GC walks the backing OopStorages concurrently. The hash function for the table is a hash of the lower 32 bits of the address. A flag is set during GC (gc_notification if in a safepoint, and through a call to JvmtiTagMap::needs_processing()) so that the table is rehashed at the next use. The gc_notification mechanism of weak oop processing is used to notify Jvmti to post ObjectFree events. In concurrent GCs there can be a window of time between weak oop marking where the oop is unmarked, so dead (the phantom load in peek returns NULL) but the gc_notification hasn't been done yet. In this window, a heap walk or GetObjectsWithTags call would not find an object before the ObjectFree event is posted. This is dealt with in two ways: 1. In the Heap walk, there's an unconditional table walk to post events if events are needed to post. 2. For GetObjectWithTags, if a dead oop is found in the table and posting is required, we use the VM thread to post the event. Event posting cannot be done in a JavaThread because the posting needs to be done while holding the table lock, so that the JvmtiEnv state doesn't change before posting is done. ObjectFree callbacks are limited in what they can do as per the JVMTI Specification. The allowed callbacks to the VM already have code to allow NonJava threads. To avoid rehashing, I also tried to use object->identity_hash() but this breaks because entries can be added to the table during heapwalk, where the objects use marking. The starting markWord is saved and restored. Adding a hashcode during this operation makes restoring the former markWord (locked, inflated, etc) too complicated. Plus we don't want all these objects to have hashcodes because locking operations after tagging would have to always use inflated locks. Much of this change is to remove serial weak oop processing for the weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with jvmti code. It has also been tested with tier1-6. Thank you to Stefan, Erik and Kim for their help with this change. ------------- Commit messages: - 8212879: Make JVMTI TagMap table not hash on oop address Changes: https://git.openjdk.java.net/jdk/pull/967/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=967&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8212879 Stats: 1737 lines in 41 files changed: 631 ins; 990 del; 116 mod Patch: https://git.openjdk.java.net/jdk/pull/967.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/967/head:pull/967 PR: https://git.openjdk.java.net/jdk/pull/967 From cjplummer at openjdk.java.net Fri Oct 30 20:38:04 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 30 Oct 2020 20:38:04 GMT Subject: RFR: 8255694: memory leak in JDWP debug agent after calling JVMTI GetAllThreads Message-ID: The debug agent needs to deallocate memory that is allocated by calls to GetAllThreads. There were two places were this was not being done, resulting in a memory leak. ------------- Commit messages: - Make sure to deallocate jthread array allocated by GetAllThreads. Changes: https://git.openjdk.java.net/jdk/pull/968/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=968&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255694 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/968.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/968/head:pull/968 PR: https://git.openjdk.java.net/jdk/pull/968 From cjplummer at openjdk.java.net Fri Oct 30 20:49:03 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 30 Oct 2020 20:49:03 GMT Subject: RFR: 8255696: JDWP debug agent's canSuspendResumeThreadLists() should be removed Message-ID: This RFR removes the debug agent's canSuspendResumeThreadLists() function and code that depends on it. Please see the CR for a description of why this is being done. ------------- Commit messages: - Remove canSuspendResumeThreadLists(). Changes: https://git.openjdk.java.net/jdk/pull/970/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=970&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255696 Stats: 33 lines in 3 files changed: 0 ins; 29 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/970.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/970/head:pull/970 PR: https://git.openjdk.java.net/jdk/pull/970 From erikj at openjdk.java.net Fri Oct 30 20:48:57 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 30 Oct 2020 20:48:57 GMT Subject: RFR: 8212879: Make JVMTI TagMap table not hash on oop address In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 20:23:04 GMT, Coleen Phillimore wrote: > This change turns the HashTable that JVMTI uses for object tagging into a regular Hotspot hashtable - the one in hashtable.hpp with resizing and rehashing. Instead of pointing directly to oops so that GC has to walk the table to follow oops and then to rehash the table, this table points to WeakHandle. GC walks the backing OopStorages concurrently. > > The hash function for the table is a hash of the lower 32 bits of the address. A flag is set during GC (gc_notification if in a safepoint, and through a call to JvmtiTagMap::needs_processing()) so that the table is rehashed at the next use. > > The gc_notification mechanism of weak oop processing is used to notify Jvmti to post ObjectFree events. In concurrent GCs there can be a window of time between weak oop marking where the oop is unmarked, so dead (the phantom load in peek returns NULL) but the gc_notification hasn't been done yet. In this window, a heap walk or GetObjectsWithTags call would not find an object before the ObjectFree event is posted. This is dealt with in two ways: > > 1. In the Heap walk, there's an unconditional table walk to post events if events are needed to post. > 2. For GetObjectWithTags, if a dead oop is found in the table and posting is required, we use the VM thread to post the event. > > Event posting cannot be done in a JavaThread because the posting needs to be done while holding the table lock, so that the JvmtiEnv state doesn't change before posting is done. ObjectFree callbacks are limited in what they can do as per the JVMTI Specification. The allowed callbacks to the VM already have code to allow NonJava threads. > > To avoid rehashing, I also tried to use object->identity_hash() but this breaks because entries can be added to the table during heapwalk, where the objects use marking. The starting markWord is saved and restored. Adding a hashcode during this operation makes restoring the former markWord (locked, inflated, etc) too complicated. Plus we don't want all these objects to have hashcodes because locking operations after tagging would have to always use inflated locks. > > Much of this change is to remove serial weak oop processing for the weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with jvmti code. > > It has also been tested with tier1-6. > > Thank you to Stefan, Erik and Kim for their help with this change. Build changes look ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/967 From cjplummer at openjdk.java.net Fri Oct 30 20:54:53 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 30 Oct 2020 20:54:53 GMT Subject: RFR: 8255696: JDWP debug agent's canSuspendResumeThreadLists() should be removed In-Reply-To: References: Message-ID: <3Okk7BC16qOZzZXO6L-hs5ReARgp8SqYtjVctJEpLh4=.93c332a1-4b77-4e0f-9834-ff0e598b7ba6@github.com> On Fri, 30 Oct 2020 20:42:24 GMT, Chris Plummer wrote: > This RFR removes the debug agent's canSuspendResumeThreadLists() function and code that depends on it. Please see the CR for a description of why this is being done. The copyright for threadControl.c will be updated by https://github.com/openjdk/jdk/pull/968, which I will push first. ------------- PR: https://git.openjdk.java.net/jdk/pull/970 From cjplummer at openjdk.java.net Fri Oct 30 21:18:02 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 30 Oct 2020 21:18:02 GMT Subject: RFR: 8255695: Some JVMTI calls in the jdwp debug agent are using FUNC_PTR instead of JVMTI_FUNC_PTR Message-ID: <9EOh170kLoAkCerX-ljRzRtlPDWr37m87C_ss2bVXDQ=.bb5632dc-97d4-4470-817e-a52a74964ba6@github.com> Use JVMTI_FUNC_PTR instead of FUNC_PTR for most JVMTI calls. See CR for details. ------------- Commit messages: - Use JVMTI_FUNC_PTR instead of FUNC_PTR for most JVMTI calls so they are logged. Changes: https://git.openjdk.java.net/jdk/pull/971/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=971&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255695 Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/971.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/971/head:pull/971 PR: https://git.openjdk.java.net/jdk/pull/971 From amenkov at openjdk.java.net Fri Oct 30 21:54:54 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 30 Oct 2020 21:54:54 GMT Subject: RFR: 8255694: memory leak in JDWP debug agent after calling JVMTI GetAllThreads In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 20:30:49 GMT, Chris Plummer wrote: > The debug agent needs to deallocate memory that is allocated by calls to GetAllThreads. There were two places were this was not being done, resulting in a memory leak. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/968 From amenkov at openjdk.java.net Fri Oct 30 22:13:58 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 30 Oct 2020 22:13:58 GMT Subject: RFR: 8255696: JDWP debug agent's canSuspendResumeThreadLists() should be removed In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 20:42:24 GMT, Chris Plummer wrote: > This RFR removes the debug agent's canSuspendResumeThreadLists() function and code that depends on it. Please see the CR for a description of why this is being done. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/970 From sspitsyn at openjdk.java.net Sat Oct 31 08:02:53 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 31 Oct 2020 08:02:53 GMT Subject: RFR: 8255696: JDWP debug agent's canSuspendResumeThreadLists() should be removed In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 20:42:24 GMT, Chris Plummer wrote: > This RFR removes the debug agent's canSuspendResumeThreadLists() function and code that depends on it. Please see the CR for a description of why this is being done. Hi Chris, It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/970 From sspitsyn at openjdk.java.net Sat Oct 31 08:12:55 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 31 Oct 2020 08:12:55 GMT Subject: RFR: 8255694: memory leak in JDWP debug agent after calling JVMTI GetAllThreads In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 20:30:49 GMT, Chris Plummer wrote: > The debug agent needs to deallocate memory that is allocated by calls to GetAllThreads. There were two places were this was not being done, resulting in a memory leak. This looks good. Nit: semicolon sign can be removed: err: ; + jvmtiDeallocate(threads); Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/968 From sspitsyn at openjdk.java.net Sat Oct 31 08:15:54 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 31 Oct 2020 08:15:54 GMT Subject: RFR: 8255695: Some JVMTI calls in the jdwp debug agent are using FUNC_PTR instead of JVMTI_FUNC_PTR In-Reply-To: <9EOh170kLoAkCerX-ljRzRtlPDWr37m87C_ss2bVXDQ=.bb5632dc-97d4-4470-817e-a52a74964ba6@github.com> References: <9EOh170kLoAkCerX-ljRzRtlPDWr37m87C_ss2bVXDQ=.bb5632dc-97d4-4470-817e-a52a74964ba6@github.com> Message-ID: On Fri, 30 Oct 2020 21:11:09 GMT, Chris Plummer wrote: > Use JVMTI_FUNC_PTR instead of FUNC_PTR for most JVMTI calls. See CR for details. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/971 From sspitsyn at openjdk.java.net Sat Oct 31 09:56:55 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 31 Oct 2020 09:56:55 GMT Subject: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop In-Reply-To: References: Message-ID: <5-JnsHKeZztip64W88tRwA9_pcuWze2jftUq0C6oYSM=.79916a5b-5dd1-402f-b1ba-0caa38a39c1b@github.com> On Thu, 29 Oct 2020 12:44:58 GMT, Erik ?sterlund wrote: > The imasm::remove_activation() call does not deal with safepoints very well. However, when the MethodExit JVMTI event is being called, we call into the runtime in the middle of remove_activation(). If the value being returned is an object type, then the top-of-stack contains the oop. However, the GC does not traverse said oop in any oop map, because it is simply not expected that we safepoint in the middle of remove_activation(). > > The JvmtiExport::post_method_exit() function we end up calling, reads the top-of-stack oop, and puts it in a handle. Then it calls JVMTI callbacks, that eventually call Java and a bunch of stuff that safepoints. So after the JVMTI callback, we can expect the top-of-stack oop to be broken. Unfortunately, when we continue, we therefore end up returning a broken oop. > > Notably, the fact that InterpreterRuntime::post_method_exit is a JRT_ENTRY, is wrong, as we can safepoint on the way back to Java, which will break the return oop in a similar way. So this patch makes it a JRT_BLOCK_ENTRY, moving the transition to VM and back, into a block of code that is protected against GC. Before the JRT_BLOCK is called, we stash away the return oop, and after the JRT_BLOCK_END, we restore the top-of-stack oop. In the path when InterpreterRuntime::post_method_exit is called when throwing an exception, we don't have the same problem of retaining an oop result, and hence the JRT_BLOCK/JRT_BLOCK_END section is not performed in this case; the logic is the same as before for this path. > > This is a JVMTI bug that has probably been around for a long time. It crashes with all GCs, but was discovered recently after concurrent stack processing, as StefanK has been running better GC stressing code in JVMTI, and the bug reproduced more easily with concurrent stack processing, as the timings were a bit different. The following reproducer failed pretty much 100% of the time: > while true; do make test JTREG="RETAIN=all" TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitEvent/returnValue/returnValue003/returnValue003.java TEST_OPTS_JAVA_OPTIONS="-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=0.0001 -XX:ZFragmentationLimit=0.01 -XX:+VerifyOops -XX:+ZVerifyViews -Xint" ; done > > With my fix I can run this repeatedly without any more failures. I have also sanity checked the patch by running tier 1-5, so that it does not introduces any new issues on its own. I have also used Stefan's nice external GC stressing with jcmd technique that was used to trigger crashes with other GCs, to make sure said crashes no longer reproduce either. Hi Erik, Nice discovery! Indeed, this is a long standing issue. It looks good in general. I agree with Coleen, it would be nice if there is an elegant way to move the oop_result saving/restoring code to InterpreterRuntime::post_method_exit. Otherwise, I'm okay with what you have now. It is also nice discovery of the issue with clearing the expression stack. I think, it was my mistake in the initial implementation of the ForceEarlyReturn when I followed the PopFrame implementation pattern. It is good to separate it from the current fix. Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/930