From yyang at openjdk.java.net Thu Apr 1 01:57:33 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 1 Apr 2021 01:57:33 GMT Subject: RFR: 8264413: Data is written to file header even if its CRC32 was calculated [v4] In-Reply-To: <8isyTd_mJ4ppJdTAalHYMfoJhnWaugFLc7EowDZiXJA=.e63c4682-aef3-4ff7-b0e8-293affaf97df@github.com> References: <8isyTd_mJ4ppJdTAalHYMfoJhnWaugFLc7EowDZiXJA=.e63c4682-aef3-4ff7-b0e8-293affaf97df@github.com> Message-ID: On Wed, 31 Mar 2021 16:00:24 GMT, Calvin Cheung wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> add new jtreg test with VerifySharedSpaces > > Marked as reviewed by ccheung (Reviewer). Thanks @calvinccheung @yminqi for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/3261 From yyang at openjdk.java.net Thu Apr 1 02:11:16 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 1 Apr 2021 02:11:16 GMT Subject: Integrated: 8264413: Data is written to file header even if its CRC32 was calculated In-Reply-To: References: Message-ID: <9GOgzZ81RrlWI0X_fq6DACrdw4X5Ds02qHP678xIe9Q=.23b50725-ffe8-454b-9bd6-963abd45243f@github.com> On Tue, 30 Mar 2021 09:25:20 GMT, Yi Yang wrote: > Many tests under `runtime/cds/appcds/dynamicArchive` are crashed when turning on VerifySharedSpaces, VM reports inconsistent crc32 between dumptime and runtime(See detailed content on JBS attachments): > > $ diff dump.log run.log > 17c17 > < - base_archive_is_default: 0 > --- >> - base_archive_is_default: 1 > 19c19 > < - base_archive_name_size: 0 > --- >> - base_archive_name_size: 113 > > The root cause is that even if the CRC32 is calculated(Line 1902), ArchiveBuilder is still writing data to FileMapInfo(Line 1903): > > https://github.com/openjdk/jdk/blob/4ea6abfbd1818fa7049bc4f6e46d568e842acb34/src/hotspot/share/memory/archiveBuilder.cpp#L1091-L1094 > > https://github.com/openjdk/jdk/blob/4ea6abfbd1818fa7049bc4f6e46d568e842acb34/src/hotspot/share/memory/filemap.cpp#L1236-L1251 > > Now the expected CRC32(serialized in CDS archive) is different from the calculated ones at runtime. This patch addresses this problem, it writes base_archive_name and size into header **before** calculating CRC32(if needed). > > Thanks~ > Yang This pull request has now been integrated. Changeset: de495df7 Author: Yi Yang Committer: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/de495df7 Stats: 98 lines in 4 files changed: 87 ins; 8 del; 3 mod 8264413: Data is written to file header even if its CRC32 was calculated Reviewed-by: ccheung, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/3261 From coleenp at openjdk.java.net Thu Apr 1 03:11:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 03:11:07 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v4] In-Reply-To: References: Message-ID: > This change reduces the length of SystemDictionary::resolve_instance_class_or_null, the main class loading function to 4 pages on my screen, down from ~6. Some functions are made static inside systemDictionary.hpp. > > The only executable change is that handle_parallel_super_load used to have a wait while the class's superclass was being loaded after calling resolve_super_or_fail. It was similar to the subsequent code that waited for the LOAD_INSTANCE placeholder, immediately following the return from handle_parallel_super_load. I consolidated this code to wait for both conditions and kept the comment from handle_parallel_super_load. This wait is now in the function handle_parallel_loading. > > I also added a new load_instance_class that calls load_instance_class_impl. The new load_instance_class does constraint checking and bookkeeping after it is called so that it can return with CHECK_NULL and not check pending exceptions. These functions aren't called outside of systemDictionary.cpp. > > I added a test to show why handle_parallel_super_load is needed (see bug for details of the deadlock that this test would get if not for handle_parallel_super_load). > > This updates comments to: > 1. rewrote ClassCircularityError detection above resolve_super_or_fail so that it made more sense to me (hope it does for others too). > 2. move comments to be near the code they describe > 3. removed some comments that referred to code somewhere else but not helpful at that location, or to describe code that was deleted or obsolete, or repetitive > 4. added a comment for resolve_instance_class_or_null > > Ran tier1-3 testing, jck vm, jck lang and our internal parallel class loading tests. Retesting with tiers 4-8 in progress (I tested an earlier version of this with no failures). Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add comment about logging placeholders. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3200/files - new: https://git.openjdk.java.net/jdk/pull/3200/files/e357d971..88431ca8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3200&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3200&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3200/head:pull/3200 PR: https://git.openjdk.java.net/jdk/pull/3200 From pchilanomate at openjdk.java.net Thu Apr 1 03:12:33 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 1 Apr 2021 03:12:33 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 08:27:35 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn 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 SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - 8257831: Suspend with handshake (review baseline) Hi Robbin, Great work! I only have minor comments. ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/3191 From pchilanomate at openjdk.java.net Thu Apr 1 03:24:37 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 1 Apr 2021 03:24:37 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 13:26:13 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.hpp line 142: > >> 140: private: >> 141: volatile bool _suspended; >> 142: volatile bool _suspend_requested; > > According to the PR description `_suspend_requested` is an optimization. > >> The "suspend requested" flag is an optimization, without it a dormant thread >> could be suspended and resumed many times and each would add a new >> asynchronous handshake. Suspend requested flag means there is already an >> asynchronous suspend handshake in queue which can be re-used, only the suspend >> flag needs to be set. > > I think there are a few places where _suspend_requested is queried by mistake instead of _suspended. Maybe it would help to prevent this if _suspend_requested was renamed to something that better describes its purpose, e.g. _has_async_suspend_handshake or similar. I also think it would be a good idea to rename it with something along those lines. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From pchilanomate at openjdk.java.net Thu Apr 1 03:29:38 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 1 Apr 2021 03:29:38 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 08:27:35 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn 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 SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - 8257831: Suspend with handshake (review baseline) src/hotspot/share/runtime/handshake.hpp line 151: > 149: > 150: bool is_suspended() { return Atomic::load(&_suspended); } > 151: void set_suspend(bool to) { return Atomic::store(&_suspended, to); } Maybe set_suspended() instead()? src/hotspot/share/runtime/objectMonitor.cpp line 436: > 434: current->set_current_pending_monitor(NULL); > 435: > 436: // We cleared the pending monitor info since we've just gotten past Comment below needs updating since it mentions ThreadBlockInVM but we are not using it anymore. src/hotspot/share/runtime/thread.cpp line 277: > 275: #endif > 276: > 277: _SR_lock = new Monitor(Mutex::suspend_resume, "SR_lock", true, Mutex::suspend_resume rank is not used by any other monitor so we could remove it. src/hotspot/share/runtime/thread.hpp line 1142: > 1140: bool java_resume(); // higher-level resume logic called by the public APIs > 1141: bool is_suspended() { return _handshake.is_suspended(); } > 1142: bool suspend_request_pending() { return _handshake.suspend_request_pending(); } If you use is_suspended() to check for suspension in objectMonitor::enter() then we can remove this method. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From pchilanomate at openjdk.java.net Thu Apr 1 03:29:40 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 1 Apr 2021 03:29:40 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:32:40 GMT, David Holmes 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/thread.cpp line 667: > >> 665: >> 666: // We wait for the thread to transition to a more usable state. >> 667: for (int i = 1; i <= SuspendRetryCount; i++) { > > You will need to obsolete SuspendRetryCount and SuspendRetryDelay. This will need a CSR request indicating why there is no deprecation step. I think we will need to do the same for flags AssertOnSuspendWaitFailure and TraceSuspendWaitFailures. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From david.holmes at oracle.com Thu Apr 1 04:35:45 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Apr 2021 14:35:45 +1000 Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: <41950cd6-80d6-685d-58fb-90a74efd4470@oracle.com> On 1/04/2021 1:29 pm, Patricio Chilano Mateo wrote: > On Wed, 31 Mar 2021 06:32:40 GMT, David Holmes 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 three commits: >>> >>> - Merge branch 'master' into SuspendInHandshake >>> - Merge branch 'master' into SuspendInHandshake >>> - 8257831: Suspend with handshake (review baseline) >> >> src/hotspot/share/runtime/thread.cpp line 667: >> >>> 665: >>> 666: // We wait for the thread to transition to a more usable state. >>> 667: for (int i = 1; i <= SuspendRetryCount; i++) { >> >> You will need to obsolete SuspendRetryCount and SuspendRetryDelay. This will need a CSR request indicating why there is no deprecation step. > > I think we will need to do the same for flags AssertOnSuspendWaitFailure and TraceSuspendWaitFailures. Well spotted - both of those flags are unused already - their use was deleted with JDK-8223312, but we overlooked dropping the flags themselves. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3191 > From jiefu at openjdk.java.net Thu Apr 1 04:48:31 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 1 Apr 2021 04:48:31 GMT Subject: RFR: 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to OOM killed In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 17:14:32 GMT, Severin Gehwolf wrote: >> Hi all, >> >> jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails on some of our testing platforms. >> This is because testMemoryFailCount [1] fails due to OOM killed. >> This test fails to avoid OOM killed [2] if memory.failcnt is always 0. >> >> The fix will print "Not OOM killed" if OOM killed doesn't happen. >> And also fix another bug if the test get returned here [3]. >> >> Testing: >> - jdk/internal/platform/docker/ hotspot/jtreg/containers on Linux/x64 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java#L80 >> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L87 >> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L96 > > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java line 120: > >> 118: oa.shouldHaveExitValue(0).shouldContain("TEST PASSED!!!"); >> 119: } >> 120: } > > Consider a broken implementation of `Metrics.systemMetrics().getMemoryFailCount()`. Wouldn't the test now (falsely) pass? > > What is the actual test output on those systems where the test fails? There should be a docker log file. Does it enter line 91? Hi @jerboaa , After more thinking, I think the reason why memory.failcnt is always 0 is that there is no swap space on the host machine. So the testMemoryFailCount should be skipped in that case. But is there any API which can be used to get the swap space size of the host machine? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3286 From iklam at openjdk.java.net Thu Apr 1 05:12:22 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 05:12:22 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v8] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 20:58:46 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with >> `java -XX:DumpLoadedClassList= .... ` >> to collect shareable class names and saved in file `` , then >> `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` >> With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. >> The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. >> New added jcmd option: >> `jcmd VM.cds static_dump ` >> or >> `jcmd VM.cds dynamic_dump ` >> To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. >> The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Fix revert unintentionally comment, merge master. > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. > - Remove redundant check for if a class is shareable > - Fix according to review comment and add more tests > - Fix filter more flags to exclude in static dump, add more test cases > - Merge branch 'master' into jdk-8259070 > - Fix white space in CDS.java > - Add function CDS.dumpSharedArchive in java to dump shared archive > - 8259070: Add jcmd option to dump CDS Changes requested by iklam (Reviewer). src/hotspot/share/services/diagnosticCommand.cpp line 1106: > 1104: output()->print_cr("Dynamic dump:"); > 1105: if (!UseSharedSpaces) { > 1106: output()->print_cr("CDS is not available for the JDK"); I think we should use a message similar to this: $ java -Xshare:off -XX:ArchiveClassesAtExit=xxx -version Error occurred during initialization of VM DynamicDumpSharedSpaces is unsupported when base CDS archive is not loaded How about "dynamic_dump is unsupported when base CDS archive is not loaded". src/hotspot/share/services/diagnosticCommand.cpp line 1125: > 1123: Symbol* cds_name = vmSymbols::jdk_internal_misc_CDS(); > 1124: Klass* cds_klass = SystemDictionary::resolve_or_fail(cds_name, true /*throw error*/, CHECK); > 1125: JavaValue result(T_OBJECT); Should be `result(T_VOID)` to match the signature of `CDS.dumpSharedArchive()` src/hotspot/share/services/diagnosticCommand.cpp line 1133: > 1131: vmSymbols::dumpSharedArchive(), > 1132: vmSymbols::dumpSharedArchive_signature(), > 1133: &args, THREAD); Should be `&args, CHECK);`. Recently, we have started to to avoid using `THREAD` if the callee function may throw an exception. src/java.base/share/classes/jdk/internal/misc/CDS.java line 218: > 216: try { > 217: PrintStream prt = new PrintStream(fileName); > 218: prt.println("Command:"); [Try-with-resources](https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html) should be used to make sure the streams are closed when the method exits (normally or on exception). try (InputStreamReader isr = new InputStreamReader(stream); BufferedReader rdr = new BufferedReader(isr); PrintStream prt = new PrintStream(fileName);) { prt.println("Command:"); .... src/java.base/share/classes/jdk/internal/misc/CDS.java line 307: > 305: outputStdStream(proc.getErrorStream(), stdErrFile, cmds); > 306: }).start(); > 307: I think the above code can be refactored to avoid duplication. Something like: String stdOutFile = drainOutput(proc.getInputStream(), "stdout"); String stdErrFile = drainOutput(proc.getErrorStream(), "stderr"); and move the common code into drainOutput(). ------------- PR: https://git.openjdk.java.net/jdk/pull/2737 From rehn at openjdk.java.net Thu Apr 1 07:20:27 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 1 Apr 2021 07:20:27 GMT Subject: RFR: 8264393: JDK-8258284 introduced dangling TLH race [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 01:57:40 GMT, Daniel D. Daugherty wrote: >> I ported some 20 year old tests using JDK-8262881 in order to help >> test [~rehn]'s fix for JDK-8257831. These tests in combination with >> one piece of the fix from JDK-8257831 revealed a bug in my fix for >> JDK-8258284 from back in Dec 2020. >> >> The race revealed by the ported tests from JDK-8262881 happens >> only with nested ThreadsListHandles. When TLH2 is destroyed, the >> thread updates its threads_hazard_ptr from the TLH2-list to the >> TLH1-list; I made this change back in 2020.12 using JDK-8258284. >> The threads_hazard_ptr can be observed by a thread calling >> ThreadsSMRSupport::free_list() as a stable ThreadsList at the same >> time as the TLH1 destructor is decrementing the nested_handle_cnt >> that permits the ThreadsList to be freed. So the thread calling >> ThreadsSMRSupport::free_list() thinks it has a stable hazard ptr >> (TLH1-list), but that hazard ptr can be freed and causes lots of >> confusion. >> >> Update: This fix along with the fix from JDK-8264123 were stress >> tested with the new tests from JDK-8262881. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR - fix nit in assert mesg. Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3272 From rehn at openjdk.java.net Thu Apr 1 07:20:27 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 1 Apr 2021 07:20:27 GMT Subject: RFR: 8264393: JDK-8258284 introduced dangling TLH race [v2] In-Reply-To: <0osQtKNvPRqpCcRkYDDvjwG8UmkGIJ0jUfQ0adifuMU=.d877e55d-8f55-4186-9ad4-55ffa7128e41@github.com> References: <5ACrc6gFyuEV5Vw_gHSc6kHlOlzspMyD4_FyJoivScQ=.4cf8de56-73d1-42ef-97c5-65e34a97c435@github.com> <88RM99jJaOKfWScLYxvuR3fMxBTGTnX7gmxsGzrzIy4=.b5b279fc-04f9-48a4-876f-ec25fc7fa77b@github.com> <0osQtKNvPRqpCcRkYDDvjwG8UmkGIJ0jUfQ0adifuMU=.d877e55d-8f55-4186-9ad4-55ffa7128e41@github.com> Message-ID: On Wed, 31 Mar 2021 16:24:11 GMT, Daniel D. Daugherty wrote: >> @robehn - Thanks for reviewing the fix. Yes, I think you have missed something. :-) >> >> I modeled the analysis of this race after one of your favorite race techniques >> in my analysis.ThreadsList.for_JBS attachment to the bug report: since there >> is nothing to force the two threads to interact with each in a particular order, >> I posited delays at various points in the execution of each thread. This quote >> from the analysis.ThreadsList.for_JBS attachment describes scenario: >> >> Race note: >> THR-1 is the thread calling the TLH destructors. >> THR-2 is the exiting thread calling ThreadsSMRSupport::free_list. >> >> If THR-2's ThreadsSMRSupport::free_list() call finishes its scan of of >> the active Threads _threads_hazard_ptr values BEFORE the TLH-2 >> destructor code sequence updates THR-1->_threads_hazard_ptr from TL-2 >> to TL-1, then TL-2 and not TL-1 will be on the list of in-use >> ThreadsLists: >> >> // Gather a hash table of the current hazard ptrs: >> ThreadScanHashtable *scan_table = new ThreadScanHashtable(hash_table_size); >> ScanHazardPtrGatherThreadsListClosure scan_cl(scan_table); >> threads_do(&scan_cl); >> >> At this point, THR-2's ThreadsSMRSupport::free_list() call stalls and >> THR-1 not only finishes the TLH-2 destructor, it also finishes its use >> of TLH-1 as described in the next section and starts to run the TLH-1 >> destructor. >> >> After the first ThreadsListHandle is released for THR-1: >> >> +----------------------------------+ >> | THR-1 | >> +----------------------------------+ >> | _threads_hazard_ptr=0 | >> | _threads_list_ptr=0 | >> | _nested_threads_hazard_ptr_cnt=0 | >> +----------------------------------+ >> >> +----------------------+ >> | TL-1 | >> +----------------------+ >> | _length=XXXXXXXXXXXX | >> | _next_list=XXXXXXXXX | >> | _threads[5]=XXXXXXXX | >> | _nested_handle_cnt=X | >> +----------------------+ >> >> Race note: >> THR-1 is running the TLH-1 destructor and has decremented the TL-1 >> _nested_handle_cnt, but stalls before it clears _threads_hazard_ptr. >> >> The THR-2's ThreadsSMRSupport::free_list() call continues executing and >> checks the _to_delete_list ThreadsLists and if they are not in the >> scan_table and have a _nested_handle_cnt == 0 then, they are freed. >> >> This is how TL-1 is freed, but still remains in THR-1's >> _threads_hazard_ptr field and can be observed later by THR-2 as a valid >> hazard ptr in its call to smr_delete() on itself or by another thread >> perusing the system ThreadsList. This is especially true after >> ThreadsSMRSupport::free_list() has finished its work and released the >> Threads_lock which will allow another thread to walk the set of hazard >> ptrs. >> >> THR-1 resumes running again and clears _threads_hazard_ptr. However, >> the other thread walking the set of hazard ptrs has the stale TL-1 >> value and tries to use it. Boom! >> >> Switching the decrement: >> `_list->dec_nested_handle_cnt()` >> to happen after the: >> `_thread->set_threads_hazard_ptr(_previous->_list)` >> doesn't help because THR-2 observed TL-2 before we >> reached that code and then THR-2 stalled until after all >> the updates were made. THR-2 recorded TL-2 in the >> collection of current hazard ptrs and THR-2 knows nothing >> about TL-1 being a valid hazard ptr so THR-2 can free it. > > I tested JDK-8264123 together with this fix (JDK-8264393) in Mach5 Tier[1-7] > and there are no regressions. Hi Dan, yes thanks. So I would say, you may not install a ThreadsList into your hazard pointer if it's on the _to_delete_list. Got it, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3272 From rehn at openjdk.java.net Thu Apr 1 07:33:36 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 1 Apr 2021 07:33:36 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 03:09:41 GMT, Patricio Chilano Mateo 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > Hi Robbin, > > Great work! I only have minor comments. I have a long easter weekend and I'm testing some stuff, so there will be a small delay, thanks for all the comments! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Thu Apr 1 09:27:25 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 1 Apr 2021 09:27:25 GMT Subject: RFR: 8264123: add ThreadsList.is_valid() support In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 21:48:23 GMT, Daniel D. Daugherty wrote: > ThreadsLists need an is_valid() function and checks in various > places to help catch bugs where a ThreadsList is dangling. > > Other minor changes: > - change raw `_threads_hazard_ptr` access to used `get_threads_hazard_ptr()`. > - `get_threads_hazard_ptr()` should be `const`. > - fix a couple of old typos. > > Update: forgot to mention that this fix was tested with Mach5 Tier[1-8]. Hi Dan, I have seen some other verification code which also might be performance impacting, can we got over and measure what the cost is for different verification when you gotten your bake time here? So we can take an informed decision based on what the cost vs debuggability in product is. Looks good, thanks. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3255 From ysuenaga at openjdk.java.net Thu Apr 1 13:03:50 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 1 Apr 2021 13:03:50 GMT Subject: RFR: 8264482: container info misleads on non-container environment [v2] In-Reply-To: References: Message-ID: > hs_err log and `VM.info` dcmd shows cgroup information as container information even though the process run on non-container environment as following. > > container (cgroup) information: > container_type: cgroupv2 > cpu_cpuset_cpus: not supported > cpu_memory_nodes: not supported > active_processor_count: 4 > cpu_quota: not supported > cpu_period: not supported > cpu_shares: not supported > memory_limit_in_bytes: unlimited > memory_and_swap_limit_in_bytes: unlimited > memory_soft_limit_in_bytes: unlimited > memory_usage_in_bytes: 164163584 > memory_max_usage_in_bytes: not supported > > We can use cgroup outside of container, so it is useful to show. However cgroup is different from container. We should distinguish them. > And also it is useful if we can see container runtime in this section. So I added it. We can see following contents in this section after this change. > > cgroup information: > cgroup_type: cgroupv2 > container runtime: podman > cpu_cpuset_cpus: not supported > cpu_memory_nodes: not supported > active_processor_count: 4 > cpu_quota: not supported > cpu_period: not supported > cpu_shares: not supported > memory_limit_in_bytes: unlimited > memory_and_swap_limit_in_bytes: unlimited > memory_soft_limit_in_bytes: unlimited > memory_usage_in_bytes: 256176128 > memory_max_usage_in_bytes: not supported > > In case of systemd, it checks PID (PID 1 or not) and `$container` in PID 1. We should check them to know the JVM runs on the container or not. > > https://github.com/systemd/systemd/blob/68337e55f62cf49b7bdfb73dc5662e23b0ea17fa/src/basic/virt.c#L619 Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Remove code to detect container runtime ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3280/files - new: https://git.openjdk.java.net/jdk/pull/3280/files/42862529..8fd9b3f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3280&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3280&range=00-01 Stats: 38 lines in 3 files changed: 0 ins; 34 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3280.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3280/head:pull/3280 PR: https://git.openjdk.java.net/jdk/pull/3280 From ysuenaga at openjdk.java.net Thu Apr 1 13:03:52 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 1 Apr 2021 13:03:52 GMT Subject: RFR: 8264482: container info misleads on non-container environment In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 14:05:37 GMT, Yasumasa Suenaga wrote: >> I'm a bit nervous about the container_runtime addition. Can this be done in a separate bug, please? What testing has been done? Has this been tested with docker and podman? Did you run tests in `test/hotspot/jtreg/containers` ? > > Thanks @jerboaa and @dholmes-ora for the comment! > I haven't aware JDK-8261242, so I will remove the code to set container runtime name. > > The reason why I sent this PR is I found "container_type" in hs_err log even though I did not run JVM on the container. It was confising. I agree to check cgroups configuration, but we should not use "container" for them. cgroups is not only for containers. > >> Did you run tests in test/hotspot/jtreg/containers ? > > I haven't run them yet. I attempted to fix `OSContainer::is_containerized()` as JDK-8261242 said, but I do not have environment to run test/hotspot/jtreg/containers test. So I fixed UL output only, and confirmed it does not affect their tests. I removed container runtime detection code - this PR changes log / hs_err / VM.info message only at result. How about this? please review it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3280 From dcubed at openjdk.java.net Thu Apr 1 17:15:08 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 1 Apr 2021 17:15:08 GMT Subject: RFR: 8264123: add ThreadsList.is_valid() support In-Reply-To: References: Message-ID: <23uII6ZbBvFcL_5q-G7h_9i5G3TyPny69iNjaSXzTKA=.d5467d06-778a-48a4-a4d5-f064b214686e@github.com> On Thu, 1 Apr 2021 09:23:48 GMT, Robbin Ehn wrote: >> ThreadsLists need an is_valid() function and checks in various >> places to help catch bugs where a ThreadsList is dangling. >> >> Other minor changes: >> - change raw `_threads_hazard_ptr` access to used `get_threads_hazard_ptr()`. >> - `get_threads_hazard_ptr()` should be `const`. >> - fix a couple of old typos. >> >> Update: forgot to mention that this fix was tested with Mach5 Tier[1-8]. > > Hi Dan, > > I have seen some other verification code which also might be performance impacting, can we got over and measure what the cost is for different verification when you gotten your bake time here? So we can take an informed decision based on what the cost vs debuggability in product is. > > Looks good, thanks. @robehn - Thanks for the review! Are you saying that I should measure the cost of these `guarantee()` calls before I switch them to `assert()` calls in the future? If that's what you mean, I'll include a note for that when I file the new bug. If that's not what you mean, please let me know what you do mean. ------------- PR: https://git.openjdk.java.net/jdk/pull/3255 From dcubed at openjdk.java.net Thu Apr 1 17:19:22 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 1 Apr 2021 17:19:22 GMT Subject: RFR: 8264393: JDK-8258284 introduced dangling TLH race [v3] In-Reply-To: References: Message-ID: <_AfHRPSv8Br7Tsd7Y8wF-_B5HT4cTJ0dpZusLGdvh3U=.4a2d560b-ed45-4d32-b04c-ee630f7c1b01@github.com> On Thu, 1 Apr 2021 07:17:20 GMT, Robbin Ehn wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes CR - fix nit in assert mesg. > > Marked as reviewed by rehn (Reviewer). @robehn - Thanks for closing the loop on your review thread. @dholmes-ora nutshell summary covers it: when clearing a nested TLH you can't simply install the previous TLH as the threads_hazard_ptr, but instead set to NULL so that it is properly set by acquire_stable_list. Another way to put it is that the `_threads_hazard_ptr` field must only be set to a non-NULL value by the acquire_stable_list() protocol. ------------- PR: https://git.openjdk.java.net/jdk/pull/3272 From dcubed at openjdk.java.net Thu Apr 1 17:19:22 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 1 Apr 2021 17:19:22 GMT Subject: RFR: 8264393: JDK-8258284 introduced dangling TLH race [v3] In-Reply-To: <_AfHRPSv8Br7Tsd7Y8wF-_B5HT4cTJ0dpZusLGdvh3U=.4a2d560b-ed45-4d32-b04c-ee630f7c1b01@github.com> References: <_AfHRPSv8Br7Tsd7Y8wF-_B5HT4cTJ0dpZusLGdvh3U=.4a2d560b-ed45-4d32-b04c-ee630f7c1b01@github.com> Message-ID: On Thu, 1 Apr 2021 17:15:53 GMT, Daniel D. Daugherty wrote: >> Marked as reviewed by rehn (Reviewer). > > @robehn - Thanks for closing the loop on your review thread. > > @dholmes-ora nutshell summary covers it: > when clearing a nested TLH you can't simply install the previous TLH as the threads_hazard_ptr, but instead set to NULL so that it is properly set by acquire_stable_list. > > Another way to put it is that the `_threads_hazard_ptr` field must only be set to > a non-NULL value by the acquire_stable_list() protocol. @fisk - since I'm tweaking your code (again), I really need you to chime in on this review thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/3272 From rehn at openjdk.java.net Thu Apr 1 17:37:25 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 1 Apr 2021 17:37:25 GMT Subject: RFR: 8264123: add ThreadsList.is_valid() support In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 09:23:48 GMT, Robbin Ehn wrote: >> ThreadsLists need an is_valid() function and checks in various >> places to help catch bugs where a ThreadsList is dangling. >> >> Other minor changes: >> - change raw `_threads_hazard_ptr` access to used `get_threads_hazard_ptr()`. >> - `get_threads_hazard_ptr()` should be `const`. >> - fix a couple of old typos. >> >> Update: forgot to mention that this fix was tested with Mach5 Tier[1-8]. > > Hi Dan, > > I have seen some other verification code which also might be performance impacting, can we got over and measure what the cost is for different verification when you gotten your bake time here? So we can take an informed decision based on what the cost vs debuggability in product is. > > Looks good, thanks. > @robehn - Thanks for the review! > > Are you saying that I should measure the cost of these `guarantee()` calls before > I switch them to `assert()` calls in the future? If that's what you mean, I'll include > a note for that when I file the new bug. If that's not what you mean, please let me > know what you do mean. Yes ------------- PR: https://git.openjdk.java.net/jdk/pull/3255 From dcubed at openjdk.java.net Thu Apr 1 19:46:39 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 1 Apr 2021 19:46:39 GMT Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v4] In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 14:10:29 GMT, Daniel D. Daugherty wrote: >> Hi Dan, >>> I figured you would enjoy this 20 year old blast from the past! >> Yes, of course, but these tests look like they have been written today! :) >> >> Thank you for making changes! >> I've just noticed one minor issue: >> >> libSuspendWithObjectMonitorEnter.cpp >> libSuspendWithObjectMonitorWait.cpp: >> The static variables below are not used and can be removed: >> 32 static jrawMonitorID threadLock = NULL; >> 33 static char threadLockName[] = "threadLock"; >> >> Thanks, >> Serguei > > @sspitsyn - Thanks for the re-review. I'll take care of the unused variables > and I'll do an audit of all three tests and look for more. Changes for the next version of the tests: - @robehn CR changes: - changed the JVM/TI function wrappers to be much simpler and just return the JVM/TI return code to the Java code caller; all error checking is now on the Java side of the test. - dropped the 'id' parameter; deleted many native support functions. @robehn - I kept the catch of UnsatisfiedLinkError because what I'm doing there is printing a nice error message and then rethrowing the same exception; it makes it easier to debug the build process for the test. @robehn - I moved the argument parsing code to the main() method; while the default configuration of the test doesn't use command line arguments, I have stress wrappers for these tests that use the command line args. @lyndseyBeil - I renamed the remaining native methods to `camelCase()` style. @sspitsyn - I've removed the unused variables from the three tests. @robehn, @lyndseyBeil and @sspitsyn - thanks for your reviews! New commit coming shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/2899 From dcubed at openjdk.java.net Thu Apr 1 19:46:38 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 1 Apr 2021 19:46:38 GMT Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v4] In-Reply-To: References: Message-ID: > Add three tests from JDK-4413752 ported to JVM/TI: > > - RawMonitorEnter() with SuspendThread() > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/SuspendWithRawMonitorEnter.java > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp > > - ObjectMonitor enter() with SuspendThread() > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp > > - ObjectMonitor wait() with SuspendThread > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp > > The Java files have a transaction diagram to show what each of the > threads in the test is doing. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Address lyndseyBeil, robehn and sspitsyn CR comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2899/files - new: https://git.openjdk.java.net/jdk/pull/2899/files/d548c7b5..28ac7069 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2899&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2899&range=02-03 Stats: 640 lines in 6 files changed: 211 ins; 309 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/2899.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2899/head:pull/2899 PR: https://git.openjdk.java.net/jdk/pull/2899 From dcubed at openjdk.java.net Thu Apr 1 19:46:39 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 1 Apr 2021 19:46:39 GMT Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v4] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 19:39:07 GMT, Daniel D. Daugherty wrote: >> @sspitsyn - Thanks for the re-review. I'll take care of the unused variables >> and I'll do an audit of all three tests and look for more. > > Changes for the next version of the tests: > > - @robehn CR changes: > - changed the JVM/TI function wrappers to be much simpler and just return the JVM/TI return code to the Java code caller; all error checking is now on the Java side of the test. > - dropped the 'id' parameter; deleted many native support functions. > > @robehn - I kept the catch of UnsatisfiedLinkError because what I'm doing there is printing a nice error message and then rethrowing the same exception; it makes it easier to debug the build process for the test. > @robehn - I moved the argument parsing code to the main() method; while the default configuration of the test doesn't use command line arguments, I have stress wrappers for these tests that use the command line args. > > @lyndseyBeil - I renamed the remaining native methods to `camelCase()` style. > > @sspitsyn - I've removed the unused variables from the three tests. > > @robehn, @lyndseyBeil and @sspitsyn - thanks for your reviews! New commit coming shortly. The v03 version was tested with Mach5 Tier[134567] testing. The three new tests passed in all configurations in all of those tiers. I also used the latest version of the tests to reproduce the failure mode that I'm hunting in "JDK-8264393 JDK-8258284 introduced dangling TLH race" so these tests still help reproduce that bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/2899 From dcubed at openjdk.java.net Thu Apr 1 19:46:39 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 1 Apr 2021 19:46:39 GMT Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v4] In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 09:02:02 GMT, Robbin Ehn wrote: >> @sspitsyn - Thanks for the review! I figured you would enjoy this 20 year old >> blast from the past! I'm tempted to ping @karenkinnear just to see if she'll >> remember these tests! >> >> I'll fix the indents in the .cpp files. Right now I'm using these tests to shake >> out @robehn's work on "JDK-8257831 Suspend with handshakes". > > Hi Dan, > > If you change the native methods, e.g. : > native static void RawMonitorEnter(int id); > To something like: > native static int RawMonitorEnter(); > > You can then handle the jvmti error in the Java code, so you don't need to pass down the 'id' of the thread. > You then remove all debug code from the C-code agent, which removes some native methods also. > Which also leads to that you don't need the thread 'id', instead you can just use the thread name, which removes some Java code. > > Also you shouldn't catch the UnsatisfiedLinkError, as docs also says: "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch." > > You also have a lot of code for argument parsing which is not used by the test inside the test methods. > Can you either remove that or if you want it put it in a separate class/method, so e.g. "doWork()" takes parsed arguments instead. > > Thanks, Robbin @robehn, @lyndseyBeil and @sspitsyn - please re-review when you get the chance. ------------- PR: https://git.openjdk.java.net/jdk/pull/2899 From dcubed at openjdk.java.net Thu Apr 1 19:58:33 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 1 Apr 2021 19:58:33 GMT Subject: RFR: 8264123: add ThreadsList.is_valid() support In-Reply-To: References: Message-ID: <95hld7ZvjPU2BBDI2e5wuRF6v_TbLJzWRjnzZIW0lN0=.cd92eb91-a52a-48be-a07e-260c566e5a92@github.com> On Thu, 1 Apr 2021 17:34:24 GMT, Robbin Ehn wrote: >> Hi Dan, >> >> I have seen some other verification code which also might be performance impacting, can we got over and measure what the cost is for different verification when you gotten your bake time here? So we can take an informed decision based on what the cost vs debuggability in product is. >> >> Looks good, thanks. > >> @robehn - Thanks for the review! >> >> Are you saying that I should measure the cost of these `guarantee()` calls before >> I switch them to `assert()` calls in the future? If that's what you mean, I'll include >> a note for that when I file the new bug. If that's not what you mean, please let me >> know what you do mean. > > Yes I've filed the following new bug: JDK-8264624 change the guarantee() calls added by JDK-8264123 to assert() calls ------------- PR: https://git.openjdk.java.net/jdk/pull/3255 From lfoltan at openjdk.java.net Thu Apr 1 20:02:17 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 1 Apr 2021 20:02:17 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v4] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 03:11:07 GMT, Coleen Phillimore wrote: >> This change reduces the length of SystemDictionary::resolve_instance_class_or_null, the main class loading function to 4 pages on my screen, down from ~6. Some functions are made static inside systemDictionary.hpp. >> >> The only executable change is that handle_parallel_super_load used to have a wait while the class's superclass was being loaded after calling resolve_super_or_fail. It was similar to the subsequent code that waited for the LOAD_INSTANCE placeholder, immediately following the return from handle_parallel_super_load. I consolidated this code to wait for both conditions and kept the comment from handle_parallel_super_load. This wait is now in the function handle_parallel_loading. >> >> I also added a new load_instance_class that calls load_instance_class_impl. The new load_instance_class does constraint checking and bookkeeping after it is called so that it can return with CHECK_NULL and not check pending exceptions. These functions aren't called outside of systemDictionary.cpp. >> >> I added a test to show why handle_parallel_super_load is needed (see bug for details of the deadlock that this test would get if not for handle_parallel_super_load). >> >> This updates comments to: >> 1. rewrote ClassCircularityError detection above resolve_super_or_fail so that it made more sense to me (hope it does for others too). >> 2. move comments to be near the code they describe >> 3. removed some comments that referred to code somewhere else but not helpful at that location, or to describe code that was deleted or obsolete, or repetitive >> 4. added a comment for resolve_instance_class_or_null >> >> Ran tier1-3 testing, jck vm, jck lang and our internal parallel class loading tests. Retesting with tiers 4-8 in progress (I tested an earlier version of this with no failures). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about logging placeholders. I think this is a good clean up to consolidate the 2 while loops Coleen into SystemDictionary::handle_parallel_loading(). A couple of minor review comments. Thanks, Lois src/hotspot/share/classfile/systemDictionary.cpp line 329: > 327: if (lt.is_enabled()) { > 328: ResourceMark rm; > 329: LogStream ls(lt); Is it helpful to pass THREAD in for the ResourceMark? src/hotspot/share/classfile/systemDictionary.cpp line 341: > 339: // parse_interfaces - from defineClass > 340: // super-class callers: > 341: // ClassFileParser - from defineClass picky review comment for line #340, comments below do not use a hyphenated "super-class", but instead one work "superclass". src/hotspot/share/classfile/systemDictionary.cpp line 492: > 490: // the superclass on the new thread internally, so we do parallel > 491: // super class loading here. This avoids deadlock for ClassCircularity > 492: // detection for parallelCapable class loaders that lock a per-class lock. "lock on a per-class lock" src/hotspot/share/classfile/systemDictionary.cpp line 534: > 532: while (oldprobe != NULL && > 533: (oldprobe->instance_load_in_progress() || oldprobe->super_load_in_progress())) { > 534: I thought in preliminary discussions we talked about adding an assert to make sure instance_load_in_progress and super_load_in_progress couldn't both be true. Am I remembering that correctly? src/hotspot/share/classfile/systemDictionary.cpp line 786: > 784: if (JvmtiExport::should_post_class_load()) { > 785: JvmtiExport::post_class_load(THREAD->as_Java_thread(), loaded_class); > 786: } This seems to be all now handled in load_instance_class, correct? ------------- PR: https://git.openjdk.java.net/jdk/pull/3200 From iklam at openjdk.java.net Thu Apr 1 20:14:28 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 20:14:28 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v4] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 03:11:07 GMT, Coleen Phillimore wrote: >> This change reduces the length of SystemDictionary::resolve_instance_class_or_null, the main class loading function to 4 pages on my screen, down from ~6. Some functions are made static inside systemDictionary.hpp. >> >> The only executable change is that handle_parallel_super_load used to have a wait while the class's superclass was being loaded after calling resolve_super_or_fail. It was similar to the subsequent code that waited for the LOAD_INSTANCE placeholder, immediately following the return from handle_parallel_super_load. I consolidated this code to wait for both conditions and kept the comment from handle_parallel_super_load. This wait is now in the function handle_parallel_loading. >> >> I also added a new load_instance_class that calls load_instance_class_impl. The new load_instance_class does constraint checking and bookkeeping after it is called so that it can return with CHECK_NULL and not check pending exceptions. These functions aren't called outside of systemDictionary.cpp. >> >> I added a test to show why handle_parallel_super_load is needed (see bug for details of the deadlock that this test would get if not for handle_parallel_super_load). >> >> This updates comments to: >> 1. rewrote ClassCircularityError detection above resolve_super_or_fail so that it made more sense to me (hope it does for others too). >> 2. move comments to be near the code they describe >> 3. removed some comments that referred to code somewhere else but not helpful at that location, or to describe code that was deleted or obsolete, or repetitive >> 4. added a comment for resolve_instance_class_or_null >> >> Ran tier1-3 testing, jck vm, jck lang and our internal parallel class loading tests. Retesting with tiers 4-8 in progress (I tested an earlier version of this with no failures). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about logging placeholders. LGTM. I like the refactoring that combines two similar code paths into the single `handle_parallel_loading` function. The subtle change in behavior probably doesn't matter, but if it did we should be able to catch it with 2+ months of testing before 17 RDP1. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3200 From lfoltan at openjdk.java.net Thu Apr 1 20:19:18 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 1 Apr 2021 20:19:18 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v4] In-Reply-To: References: Message-ID: <71OoS5S56YFYqu-FLcBuI-rUesr4ysUKJqljgSzwz7M=.d44ce1d8-ba6e-499f-afcf-cf10877a0438@github.com> On Thu, 1 Apr 2021 03:11:07 GMT, Coleen Phillimore wrote: >> This change reduces the length of SystemDictionary::resolve_instance_class_or_null, the main class loading function to 4 pages on my screen, down from ~6. Some functions are made static inside systemDictionary.hpp. >> >> The only executable change is that handle_parallel_super_load used to have a wait while the class's superclass was being loaded after calling resolve_super_or_fail. It was similar to the subsequent code that waited for the LOAD_INSTANCE placeholder, immediately following the return from handle_parallel_super_load. I consolidated this code to wait for both conditions and kept the comment from handle_parallel_super_load. This wait is now in the function handle_parallel_loading. >> >> I also added a new load_instance_class that calls load_instance_class_impl. The new load_instance_class does constraint checking and bookkeeping after it is called so that it can return with CHECK_NULL and not check pending exceptions. These functions aren't called outside of systemDictionary.cpp. >> >> I added a test to show why handle_parallel_super_load is needed (see bug for details of the deadlock that this test would get if not for handle_parallel_super_load). >> >> This updates comments to: >> 1. rewrote ClassCircularityError detection above resolve_super_or_fail so that it made more sense to me (hope it does for others too). >> 2. move comments to be near the code they describe >> 3. removed some comments that referred to code somewhere else but not helpful at that location, or to describe code that was deleted or obsolete, or repetitive >> 4. added a comment for resolve_instance_class_or_null >> >> Ran tier1-3 testing, jck vm, jck lang and our internal parallel class loading tests. Retesting with tiers 4-8 in progress (I tested an earlier version of this with no failures). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about logging placeholders. Marked as reviewed by lfoltan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3200 From coleenp at openjdk.java.net Thu Apr 1 20:40:25 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 20:40:25 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v4] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 03:11:07 GMT, Coleen Phillimore wrote: >> This change reduces the length of SystemDictionary::resolve_instance_class_or_null, the main class loading function to 4 pages on my screen, down from ~6. Some functions are made static inside systemDictionary.hpp. >> >> The only executable change is that handle_parallel_super_load used to have a wait while the class's superclass was being loaded after calling resolve_super_or_fail. It was similar to the subsequent code that waited for the LOAD_INSTANCE placeholder, immediately following the return from handle_parallel_super_load. I consolidated this code to wait for both conditions and kept the comment from handle_parallel_super_load. This wait is now in the function handle_parallel_loading. >> >> I also added a new load_instance_class that calls load_instance_class_impl. The new load_instance_class does constraint checking and bookkeeping after it is called so that it can return with CHECK_NULL and not check pending exceptions. These functions aren't called outside of systemDictionary.cpp. >> >> I added a test to show why handle_parallel_super_load is needed (see bug for details of the deadlock that this test would get if not for handle_parallel_super_load). >> >> This updates comments to: >> 1. rewrote ClassCircularityError detection above resolve_super_or_fail so that it made more sense to me (hope it does for others too). >> 2. move comments to be near the code they describe >> 3. removed some comments that referred to code somewhere else but not helpful at that location, or to describe code that was deleted or obsolete, or repetitive >> 4. added a comment for resolve_instance_class_or_null >> >> Ran tier1-3 testing, jck vm, jck lang and our internal parallel class loading tests. Retesting with tiers 4-8 in progress (I tested an earlier version of this with no failures). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about logging placeholders. Thank you for the comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/3200 From coleenp at openjdk.java.net Thu Apr 1 20:40:25 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 20:40:25 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v4] In-Reply-To: References: Message-ID: <7-PiUBb6Ws99Pd9TRvV20A4GV2n05YO0Dq0g3w1z6Fk=.4fbc3140-120e-4ddf-926c-33bc0cf729fb@github.com> On Thu, 1 Apr 2021 20:36:51 GMT, Coleen Phillimore wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment about logging placeholders. > > Thank you for the comments. Thanks Ioi for reviewing. I think the refactoring of the waiting loops will make it easier to work with if there is a subtle change in behavior. I could add a conditional to the function instead of the duplicated code. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3200 From coleenp at openjdk.java.net Thu Apr 1 20:40:27 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 20:40:27 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v4] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 19:55:38 GMT, Lois Foltan wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment about logging placeholders. > > src/hotspot/share/classfile/systemDictionary.cpp line 329: > >> 327: if (lt.is_enabled()) { >> 328: ResourceMark rm; >> 329: LogStream ls(lt); > > Is it helpful to pass THREAD in for the ResourceMark? Yes, I have a THREAD handy. > src/hotspot/share/classfile/systemDictionary.cpp line 341: > >> 339: // parse_interfaces - from defineClass >> 340: // super-class callers: >> 341: // ClassFileParser - from defineClass > > picky review comment for line #340, comments below do not use a hyphenated "super-class", but instead one work "superclass". Ok. How about a space? Because the sentence has super-class and super-interface, so I want to change them both to super class and super interface. Or should it be superclass and superinterface ? > src/hotspot/share/classfile/systemDictionary.cpp line 492: > >> 490: // the superclass on the new thread internally, so we do parallel >> 491: // super class loading here. This avoids deadlock for ClassCircularity >> 492: // detection for parallelCapable class loaders that lock a per-class lock. > > "lock on a per-class lock" Ok. > src/hotspot/share/classfile/systemDictionary.cpp line 534: > >> 532: while (oldprobe != NULL && >> 533: (oldprobe->instance_load_in_progress() || oldprobe->super_load_in_progress())) { >> 534: > > I thought in preliminary discussions we talked about adding an assert to make sure instance_load_in_progress and super_load_in_progress couldn't both be true. Am I remembering that correctly? We were talking about when instance_load_in_progress is false, then we thought we should add an assert that super_load_in_progress is also false, but super_load could still be going on for parallel threads and we have to wait for them too. ie. I tried this and found this out. We have to wait for both conditions. > src/hotspot/share/classfile/systemDictionary.cpp line 786: > >> 784: if (JvmtiExport::should_post_class_load()) { >> 785: JvmtiExport::post_class_load(THREAD->as_Java_thread(), loaded_class); >> 786: } > > This seems to be all now handled in load_instance_class, correct? Yes, I moved this down to that function. ------------- PR: https://git.openjdk.java.net/jdk/pull/3200 From coleenp at openjdk.java.net Thu Apr 1 20:40:28 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 20:40:28 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v2] In-Reply-To: References: <5dGoCOxgLd9vFQhbN7DHchPDJNOrFCKYjaN3vJPHYQY=.a2b6912d-a1cb-47ad-9341-bbcba18509db@github.com> Message-ID: On Wed, 31 Mar 2021 23:55:47 GMT, Ioi Lam wrote: >> Since nobody wants to read this example in this comment and neither do I, I'm removing it. Debugging this using -Xlog:class+load+placeholders=debug will show the stacking of placeholders that detect CCE. > > I guess it's OK to remove this comment, since most of us who have looked at this code in the past few years haven't found this comment to be helpful. Maybe you can add a comment about `-Xlog:class+load+placeholders=debug` instead? > > If we do want to improve the comment, maybe we can replacing Base->Super with something like Car->Vehicle. That way it's clear which is the supertype. Thanks Ioi. ------------- PR: https://git.openjdk.java.net/jdk/pull/3200 From coleenp at openjdk.java.net Thu Apr 1 20:59:17 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 20:59:17 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v5] In-Reply-To: References: Message-ID: > This change reduces the length of SystemDictionary::resolve_instance_class_or_null, the main class loading function to 4 pages on my screen, down from ~6. Some functions are made static inside systemDictionary.hpp. > > The only executable change is that handle_parallel_super_load used to have a wait while the class's superclass was being loaded after calling resolve_super_or_fail. It was similar to the subsequent code that waited for the LOAD_INSTANCE placeholder, immediately following the return from handle_parallel_super_load. I consolidated this code to wait for both conditions and kept the comment from handle_parallel_super_load. This wait is now in the function handle_parallel_loading. > > I also added a new load_instance_class that calls load_instance_class_impl. The new load_instance_class does constraint checking and bookkeeping after it is called so that it can return with CHECK_NULL and not check pending exceptions. These functions aren't called outside of systemDictionary.cpp. > > I added a test to show why handle_parallel_super_load is needed (see bug for details of the deadlock that this test would get if not for handle_parallel_super_load). > > This updates comments to: > 1. rewrote ClassCircularityError detection above resolve_super_or_fail so that it made more sense to me (hope it does for others too). > 2. move comments to be near the code they describe > 3. removed some comments that referred to code somewhere else but not helpful at that location, or to describe code that was deleted or obsolete, or repetitive > 4. added a comment for resolve_instance_class_or_null > > Ran tier1-3 testing, jck vm, jck lang and our internal parallel class loading tests. Retesting with tiers 4-8 in progress (I tested an earlier version of this with no failures). Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Change super class to superclass/superinterface to match the spec which makes them one word. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3200/files - new: https://git.openjdk.java.net/jdk/pull/3200/files/88431ca8..4f1b42d5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3200&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3200&range=03-04 Stats: 19 lines in 1 file changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/3200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3200/head:pull/3200 PR: https://git.openjdk.java.net/jdk/pull/3200 From coleenp at openjdk.java.net Thu Apr 1 21:00:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 21:00:48 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v6] In-Reply-To: References: Message-ID: > This change reduces the length of SystemDictionary::resolve_instance_class_or_null, the main class loading function to 4 pages on my screen, down from ~6. Some functions are made static inside systemDictionary.hpp. > > The only executable change is that handle_parallel_super_load used to have a wait while the class's superclass was being loaded after calling resolve_super_or_fail. It was similar to the subsequent code that waited for the LOAD_INSTANCE placeholder, immediately following the return from handle_parallel_super_load. I consolidated this code to wait for both conditions and kept the comment from handle_parallel_super_load. This wait is now in the function handle_parallel_loading. > > I also added a new load_instance_class that calls load_instance_class_impl. The new load_instance_class does constraint checking and bookkeeping after it is called so that it can return with CHECK_NULL and not check pending exceptions. These functions aren't called outside of systemDictionary.cpp. > > I added a test to show why handle_parallel_super_load is needed (see bug for details of the deadlock that this test would get if not for handle_parallel_super_load). > > This updates comments to: > 1. rewrote ClassCircularityError detection above resolve_super_or_fail so that it made more sense to me (hope it does for others too). > 2. move comments to be near the code they describe > 3. removed some comments that referred to code somewhere else but not helpful at that location, or to describe code that was deleted or obsolete, or repetitive > 4. added a comment for resolve_instance_class_or_null > > Ran tier1-3 testing, jck vm, jck lang and our internal parallel class loading tests. Retesting with tiers 4-8 in progress (I tested an earlier version of this with no failures). Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: fix THREAD ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3200/files - new: https://git.openjdk.java.net/jdk/pull/3200/files/4f1b42d5..5cf6aa61 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3200&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3200&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3200/head:pull/3200 PR: https://git.openjdk.java.net/jdk/pull/3200 From coleenp at openjdk.java.net Thu Apr 1 21:05:17 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 21:05:17 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v4] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 20:24:10 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/systemDictionary.cpp line 341: >> >>> 339: // parse_interfaces - from defineClass >>> 340: // super-class callers: >>> 341: // ClassFileParser - from defineClass >> >> picky review comment for line #340, comments below do not use a hyphenated "super-class", but instead one work "superclass". > > Ok. How about a space? Because the sentence has super-class and super-interface, so I want to change them both to super class and super interface. Or should it be superclass and superinterface ? Lois pointed out that the spec uses superclass and superinterface, so I changed the comments to use this convention. ------------- PR: https://git.openjdk.java.net/jdk/pull/3200 From coleenp at openjdk.java.net Thu Apr 1 21:20:27 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 21:20:27 GMT Subject: RFR: 8262046: Clean up parallel class loading code and comments [v4] In-Reply-To: <7-PiUBb6Ws99Pd9TRvV20A4GV2n05YO0Dq0g3w1z6Fk=.4fbc3140-120e-4ddf-926c-33bc0cf729fb@github.com> References: <7-PiUBb6Ws99Pd9TRvV20A4GV2n05YO0Dq0g3w1z6Fk=.4fbc3140-120e-4ddf-926c-33bc0cf729fb@github.com> Message-ID: On Thu, 1 Apr 2021 20:38:24 GMT, Coleen Phillimore wrote: >> Thank you for the comments. > > Thanks Ioi for reviewing. I think the refactoring of the waiting loops will make it easier to work with if there is a subtle change in behavior. I could add a conditional to the function instead of the duplicated code. > Thanks! Thank you Lois and Ioi for reviewing this and discussions about these changes! ------------- PR: https://git.openjdk.java.net/jdk/pull/3200 From coleenp at openjdk.java.net Thu Apr 1 21:20:28 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 21:20:28 GMT Subject: Integrated: 8262046: Clean up parallel class loading code and comments In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 17:23:42 GMT, Coleen Phillimore wrote: > This change reduces the length of SystemDictionary::resolve_instance_class_or_null, the main class loading function to 4 pages on my screen, down from ~6. Some functions are made static inside systemDictionary.hpp. > > The only executable change is that handle_parallel_super_load used to have a wait while the class's superclass was being loaded after calling resolve_super_or_fail. It was similar to the subsequent code that waited for the LOAD_INSTANCE placeholder, immediately following the return from handle_parallel_super_load. I consolidated this code to wait for both conditions and kept the comment from handle_parallel_super_load. This wait is now in the function handle_parallel_loading. > > I also added a new load_instance_class that calls load_instance_class_impl. The new load_instance_class does constraint checking and bookkeeping after it is called so that it can return with CHECK_NULL and not check pending exceptions. These functions aren't called outside of systemDictionary.cpp. > > I added a test to show why handle_parallel_super_load is needed (see bug for details of the deadlock that this test would get if not for handle_parallel_super_load). > > This updates comments to: > 1. rewrote ClassCircularityError detection above resolve_super_or_fail so that it made more sense to me (hope it does for others too). > 2. move comments to be near the code they describe > 3. removed some comments that referred to code somewhere else but not helpful at that location, or to describe code that was deleted or obsolete, or repetitive > 4. added a comment for resolve_instance_class_or_null > > Ran tier1-3 testing, jck vm, jck lang and our internal parallel class loading tests. Retesting with tiers 4-8 in progress (I tested an earlier version of this with no failures). This pull request has now been integrated. Changeset: 5e59d28d Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/5e59d28d Stats: 835 lines in 11 files changed: 608 ins; 115 del; 112 mod 8262046: Clean up parallel class loading code and comments Reviewed-by: lfoltan, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3200 From ysuenaga at openjdk.java.net Fri Apr 2 00:08:07 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 2 Apr 2021 00:08:07 GMT Subject: RFR: 8264482: container info misleads on non-container environment In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 13:00:32 GMT, Yasumasa Suenaga wrote: >> Thanks @jerboaa and @dholmes-ora for the comment! >> I haven't aware JDK-8261242, so I will remove the code to set container runtime name. >> >> The reason why I sent this PR is I found "container_type" in hs_err log even though I did not run JVM on the container. It was confising. I agree to check cgroups configuration, but we should not use "container" for them. cgroups is not only for containers. >> >>> Did you run tests in test/hotspot/jtreg/containers ? >> >> I haven't run them yet. I attempted to fix `OSContainer::is_containerized()` as JDK-8261242 said, but I do not have environment to run test/hotspot/jtreg/containers test. So I fixed UL output only, and confirmed it does not affect their tests. > > I removed container runtime detection code - this PR changes log / hs_err / VM.info message only at result. > How about this? please review it. Commit 8fd9b3f95d40783ef3b70769ba0381f55df832a5 seems to fail on macOS x64 (hs/tier1 compiler) tests, but I think it is not caused by this change because I modified Linux code only. ------------- PR: https://git.openjdk.java.net/jdk/pull/3280 From jiefu at openjdk.java.net Fri Apr 2 04:03:45 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 2 Apr 2021 04:03:45 GMT Subject: RFR: 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to OOM killed [v2] In-Reply-To: References: Message-ID: > Hi all, > > jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails on some of our testing platforms. > This is because testMemoryFailCount [1] fails due to OOM killed. > This test fails to avoid OOM killed [2] if memory.failcnt is always 0. > > The fix will print "Not OOM killed" if OOM killed doesn't happen. > And also fix another bug if the test get returned here [3]. > > Testing: > - jdk/internal/platform/docker/ hotspot/jtreg/containers on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java#L80 > [2] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L87 > [3] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L96 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Check swapping before testing ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3286/files - new: https://git.openjdk.java.net/jdk/pull/3286/files/09468a16..3e1c446d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3286&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3286&range=00-01 Stats: 28 lines in 2 files changed: 16 ins; 6 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3286.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3286/head:pull/3286 PR: https://git.openjdk.java.net/jdk/pull/3286 From jiefu at openjdk.java.net Fri Apr 2 04:13:31 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 2 Apr 2021 04:13:31 GMT Subject: RFR: 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to swapping not working [v2] In-Reply-To: References: Message-ID: <2QcFEnqjBIO1DIk7JmObayDiCVH9cvmyHOIZVrpznDY=.f3abf768-3a06-4525-9c36-3b2ba39a2e2a@github.com> On Thu, 1 Apr 2021 04:44:48 GMT, Jie Fu wrote: >> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java line 120: >> >>> 118: oa.shouldHaveExitValue(0).shouldContain("TEST PASSED!!!"); >>> 119: } >>> 120: } >> >> Consider a broken implementation of `Metrics.systemMetrics().getMemoryFailCount()`. Wouldn't the test now (falsely) pass? >> >> What is the actual test output on those systems where the test fails? There should be a docker log file. Does it enter line 91? > > Hi @jerboaa , > > After more thinking, I think the reason why memory.failcnt is always 0 is that there is no swap space on the host machine. > So the testMemoryFailCount should be skipped in that case. > > But is there any API which can be used to get the swap space size of the host machine? > > Thanks. > Consider a broken implementation of `Metrics.systemMetrics().getMemoryFailCount()`. Wouldn't the test now (falsely) pass? Hi @jerboaa , A pre-test run has been added to check whether swapping really works for testMemoryFailCount. Swapping should be OK for memory.failcnt testing otherwise it will fail due to OOM killed. What do you think? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3286 From yyang at openjdk.java.net Fri Apr 2 07:38:32 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 07:38:32 GMT Subject: RFR: 8263028: Windows build fails due to several treat-warning-as-errors In-Reply-To: References: <6cv_HeWJ9HsBrB7NSFU-TGl4PP0Tp820KzwJ-FRn_so=.e4d8ab11-4203-4278-a829-43b6f1626465@github.com> <_4snjvydeDKDu6aZgC1Fqr_kc6sHII7F7Ywinh3H9Rw=.61007752-81c3-44a0-911f-4dd184259966@github.com> Message-ID: On Mon, 29 Mar 2021 14:42:00 GMT, Yi Yang wrote: >> I searched the net once more for setting the locale, and this time I found some creative workarounds on superuser. The suggestion is to create a *secondary* user account, and set US English as locale for that account. Then you can go back to your main account, and us the "Run as..." functionality to execute an arbitrary command as that user. >> >> This could be done by: `%comspec% runas /profile /user:yourotheruser "the_application_you_want_ to_run_in_english"` or using the GUI (shift+right click on the icon, select `Run as different user`). >> >> I assume you would be able to start a cygwin shell like this, and have all processes started in that shell belonging to this US English user. >> >> @kelthuzadx Can you please verify if this method works? If so, I believe it is convenient enough for us to be able to require US English locale for building on Windows. > > Hi Magnus, > >> I searched the net once more for setting the locale, and this time I found some creative workarounds on superuser. The suggestion is to create a secondary user account, and set US English as locale for that account. Then you can go back to your main account, and us the "Run as..." functionality to execute an arbitrary command as that user. > >> This could be done by: %comspec% runas /profile /user:yourotheruser "the_application_you_want_ to_run_in_english" or using the GUI (shift+right click on the icon, select Run as different user). > > Thanks for your investigations and kind suggestions. It is more troublesome to add new a user to the Chinese system and set its system locale to English. Instead of doing this, I prefer to directly change the system locale to English. > > When I set the system locale to English(`Control Panel->Change date, time,...->Administrative->Change System locale->English`), and it indeed works for building! No warnings were generated. All works fine. > >> a) it does not occur in what is at least the "recommended" locale, and > >> b) more issues are likely to creep up in the future (in fact, there might already be testing issues as Jorn says) > >> On the other hand, I am not really comfortable either with just stating in the build document that US English is the only supported Windows locale, since it has such far-reaching consequences for the individual developers. > > You convinced me, I agree with you that stating these has far-reaching consequences and your internal test matrix will become incredibly heavy. However, I think we can add a section in the FAQ or other places in the building document to give a solution for such problems as much as possible, e.g. > > Q: Why I can not build JDK on a non-English system? What should I do next? > A: Maybe you can change your system locale to English and try again > > Just IMHO, :-) > > Best Regards, > Yang In order to avoid disturbing others, I will comment on the https://bugs.openjdk.java.net/browse/JDK-8264425 ------------- PR: https://git.openjdk.java.net/jdk/pull/3107 From yyang at openjdk.java.net Fri Apr 2 07:38:32 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 07:38:32 GMT Subject: Withdrawn: 8263028: Windows build fails due to several treat-warning-as-errors In-Reply-To: References: Message-ID: On Sun, 21 Mar 2021 04:22:42 GMT, Yi Yang wrote: > cl.exe(19.28.29334) can not build JDK on windows_x64 because it treats many warnings as errors thus prohibiting further compilation. (See detailed failure logs on JBS) > > 1. methodMatcher.cpp > > cl.exe can not handle advanced usage of sscanf(i.e. regex-like sscanf) correctly. This looks like an msvc compiler bug, it has been there for a long while, so I temporarily disable these warnings in a limited region. Outside of this region, the compiler still treats them as errors. This change does not affect the functionality of MethodMatcher::parse_method_pattern, it can parse class name and method name in a desired manner. > > 2. vm_version_x86.cpp > > Some comments contain characters(Register Trademark) that cannot be represented in the current code page (936). Replacing them with ASCII-characters makes the compiler happy. > > Best Regards, > Yang This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3107 From yyang at openjdk.java.net Fri Apr 2 08:23:40 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 08:23:40 GMT Subject: RFR: 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive Message-ID: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/classfile/classLoaderData.cpp:316), pid=68929, tid=68930 # assert(_keep_alive > 0) failed: Invalid keep alive decrement count # # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.qingfengyy.jdk) # Java VM: OpenJDK 64-Bit Server VM (slowdebug 17-internal+0-adhoc.qingfengyy.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 Stack: [0x00007f1593072000,0x00007f1593173000], sp=0x00007f1593171c00, free space=1023k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 V [libjvm.so+0xef19e7] MetaspaceShared::link_and_cleanup_shared_classes(Thread*)+0x181 V [libjvm.so+0x1260834] JavaThread::invoke_shutdown_hooks()+0x46 V [libjvm.so+0x12609e5] Threads::destroy_vm()+0xe7 V [libjvm.so+0xbb40ec] jni_DestroyJavaVM_inner+0x91 V [libjvm.so+0xbb4147] jni_DestroyJavaVM+0x1f C [libjli.so+0x4b4f] JavaMain+0xc61 C [libjli.so+0xad93] ThreadJavaMain+0x27 We observed VM crashed when dumping dynamic archive in a simple springboot application(See detailed content on JBS attachment). I did some investigations. In rare case, both of the following paths may be stepped on when dumping dynamic archive: 1. SIGINT at java.lang.Shutdown.beforeHalt(java.base at 17-internal/Native Method) at java.lang.Shutdown.exit(java.base at 17-internal/Shutdown.java:172) - locked <0x00000007fef02040> (a java.lang.Class for java.lang.Shutdown) at java.lang.Terminator$1.handle(java.base at 17-internal/Terminator.java:51) at jdk.internal.misc.Signal$1.run(java.base at 17-internal/Signal.java:219) at java.lang.Thread.run(java.base at 17-internal/Thread.java:831) 2. Normal Exit JavaThread::invoke_shutdown_hooks()+0x46 Threads::destroy_vm()+0xe7 jni_DestroyJavaVM_inner+0x91 jni_DestroyJavaVM+0x1f JavaMain+0xc61 ThreadJavaMain+0x27 They would call MetaspaceShared::link_and_cleanup_shared_classes, and CollectCLDClosure collects duplicated CLDs into _loaded_cld, _keep_alive is decrementing twice, causing a negative _keep_alive. Testing(linux_x64): [+] test/hotspot/jtreg/runtime/cds [+] test/hotspot/jtreg/gc ------------- Commit messages: - CollectCLDClosure collects duplicated CLDs when dumping dynamic archive Changes: https://git.openjdk.java.net/jdk/pull/3320/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3320&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264634 Stats: 21 lines in 2 files changed: 8 ins; 5 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3320/head:pull/3320 PR: https://git.openjdk.java.net/jdk/pull/3320 From yyang at openjdk.java.net Fri Apr 2 10:21:56 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 10:21:56 GMT Subject: RFR: 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive [v2] In-Reply-To: References: Message-ID: <0Xeiro7_nan2N7VDrDRuGY-dSDPpNALo4j6uXHpxmB4=.3be532fb-ac15-4dc0-a70a-a2a5c2b5b205@github.com> > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/classfile/classLoaderData.cpp:316), pid=68929, tid=68930 > # assert(_keep_alive > 0) failed: Invalid keep alive decrement count > # > # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.qingfengyy.jdk) > # Java VM: OpenJDK 64-Bit Server VM (slowdebug 17-internal+0-adhoc.qingfengyy.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 > > Stack: [0x00007f1593072000,0x00007f1593173000], sp=0x00007f1593171c00, free space=1023k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 > V [libjvm.so+0xef19e7] MetaspaceShared::link_and_cleanup_shared_classes(Thread*)+0x181 > V [libjvm.so+0x1260834] JavaThread::invoke_shutdown_hooks()+0x46 > V [libjvm.so+0x12609e5] Threads::destroy_vm()+0xe7 > V [libjvm.so+0xbb40ec] jni_DestroyJavaVM_inner+0x91 > V [libjvm.so+0xbb4147] jni_DestroyJavaVM+0x1f > C [libjli.so+0x4b4f] JavaMain+0xc61 > C [libjli.so+0xad93] ThreadJavaMain+0x27 > We observed VM crashed when dumping dynamic archive in a simple springboot application(See detailed content on JBS attachment). I did some investigations. In rare case, both of the following paths may be stepped on when dumping dynamic archive: > > 1. SIGINT > at java.lang.Shutdown.beforeHalt(java.base at 17-internal/Native Method) > at java.lang.Shutdown.exit(java.base at 17-internal/Shutdown.java:172) > - locked <0x00000007fef02040> (a java.lang.Class for java.lang.Shutdown) > at java.lang.Terminator$1.handle(java.base at 17-internal/Terminator.java:51) > at jdk.internal.misc.Signal$1.run(java.base at 17-internal/Signal.java:219) > at java.lang.Thread.run(java.base at 17-internal/Thread.java:831) > > 2. Normal Exit > JavaThread::invoke_shutdown_hooks()+0x46 > Threads::destroy_vm()+0xe7 > jni_DestroyJavaVM_inner+0x91 > jni_DestroyJavaVM+0x1f > JavaMain+0xc61 > ThreadJavaMain+0x27 > > They would call MetaspaceShared::link_and_cleanup_shared_classes, and CollectCLDClosure collects duplicated CLDs into _loaded_cld, _keep_alive is decrementing twice, causing a negative _keep_alive. > > Testing(linux_x64): > [+] test/hotspot/jtreg/runtime/cds > [+] test/hotspot/jtreg/gc Yi Yang 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: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3320/files - new: https://git.openjdk.java.net/jdk/pull/3320/files/bdc9c723..56a47fce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3320&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3320&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3320/head:pull/3320 PR: https://git.openjdk.java.net/jdk/pull/3320 From sspitsyn at openjdk.java.net Fri Apr 2 17:49:21 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 2 Apr 2021 17:49:21 GMT Subject: RFR: 8264311: Heap object statistics In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 21:46:12 GMT, Mikhailo Seledtsov wrote: >> I'm not involved in the Lilliput project, but as long as the stakeholders are ok with that approach, it's probably the way to go, especially since you seem to think the feature might still evolve some. > > If you are planning to integrate this change to jdk/jdk, please make sure to provide tests for this enhancement. Hi Roman, Do you have any test case verifying this? Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/3271 From rkennke at openjdk.java.net Fri Apr 2 18:59:21 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 2 Apr 2021 18:59:21 GMT Subject: RFR: 8264311: Heap object statistics In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 17:46:35 GMT, Serguei Spitsyn wrote: > Hi Roman, > Do you have any test case verifying this? > Thanks, > Serguei Hi Serguei, no, not yet, but I will add some. Thanks for the suggestion! ------------- PR: https://git.openjdk.java.net/jdk/pull/3271 From minqi at openjdk.java.net Fri Apr 2 19:27:59 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 2 Apr 2021 19:27:59 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v9] In-Reply-To: References: Message-ID: <_jXjltEgPfLS6x74d5Q3UfwNXMsRvqyM_9-sDzVDcAg=.38d5f001-5351-4208-98d9-42002aecdd19@github.com> > Hi, Please review > > Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with > `java -XX:DumpLoadedClassList= .... ` > to collect shareable class names and saved in file `` , then > `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` > With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. > The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. > New added jcmd option: > `jcmd VM.cds static_dump ` > or > `jcmd VM.cds dynamic_dump ` > To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. > The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Fix revert unintentionally comment, merge master. - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. - Remove redundant check for if a class is shareable - Fix according to review comment and add more tests - Fix filter more flags to exclude in static dump, add more test cases - Merge branch 'master' into jdk-8259070 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/328e9514...79822e79 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2737/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=08 Stats: 846 lines in 23 files changed: 772 ins; 58 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/2737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737 PR: https://git.openjdk.java.net/jdk/pull/2737 From minqi at openjdk.java.net Fri Apr 2 21:58:18 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 2 Apr 2021 21:58:18 GMT Subject: RFR: 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive [v2] In-Reply-To: <0Xeiro7_nan2N7VDrDRuGY-dSDPpNALo4j6uXHpxmB4=.3be532fb-ac15-4dc0-a70a-a2a5c2b5b205@github.com> References: <0Xeiro7_nan2N7VDrDRuGY-dSDPpNALo4j6uXHpxmB4=.3be532fb-ac15-4dc0-a70a-a2a5c2b5b205@github.com> Message-ID: <3j2GXrtHpavIufN5v2QhkOGRUVyoBmvk3KmUKGpGAf0=.a230bd13-5e48-4465-b42c-1b6ea8ffb856@github.com> On Fri, 2 Apr 2021 10:21:56 GMT, Yi Yang wrote: >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/classfile/classLoaderData.cpp:316), pid=68929, tid=68930 >> # assert(_keep_alive > 0) failed: Invalid keep alive decrement count >> # >> # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.qingfengyy.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 17-internal+0-adhoc.qingfengyy.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 >> >> Stack: [0x00007f1593072000,0x00007f1593173000], sp=0x00007f1593171c00, free space=1023k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 >> V [libjvm.so+0xef19e7] MetaspaceShared::link_and_cleanup_shared_classes(Thread*)+0x181 >> V [libjvm.so+0x1260834] JavaThread::invoke_shutdown_hooks()+0x46 >> V [libjvm.so+0x12609e5] Threads::destroy_vm()+0xe7 >> V [libjvm.so+0xbb40ec] jni_DestroyJavaVM_inner+0x91 >> V [libjvm.so+0xbb4147] jni_DestroyJavaVM+0x1f >> C [libjli.so+0x4b4f] JavaMain+0xc61 >> C [libjli.so+0xad93] ThreadJavaMain+0x27 >> We observed VM crashed when dumping dynamic archive in a simple springboot application(See detailed content on JBS attachment). I did some investigations. In rare case, both of the following paths may be stepped on when dumping dynamic archive: >> >> 1. SIGINT >> at java.lang.Shutdown.beforeHalt(java.base at 17-internal/Native Method) >> at java.lang.Shutdown.exit(java.base at 17-internal/Shutdown.java:172) >> - locked <0x00000007fef02040> (a java.lang.Class for java.lang.Shutdown) >> at java.lang.Terminator$1.handle(java.base at 17-internal/Terminator.java:51) >> at jdk.internal.misc.Signal$1.run(java.base at 17-internal/Signal.java:219) >> at java.lang.Thread.run(java.base at 17-internal/Thread.java:831) >> >> 2. Normal Exit >> JavaThread::invoke_shutdown_hooks()+0x46 >> Threads::destroy_vm()+0xe7 >> jni_DestroyJavaVM_inner+0x91 >> jni_DestroyJavaVM+0x1f >> JavaMain+0xc61 >> ThreadJavaMain+0x27 >> >> They would call MetaspaceShared::link_and_cleanup_shared_classes, and CollectCLDClosure collects duplicated CLDs into _loaded_cld, _keep_alive is decrementing twice, causing a negative _keep_alive. >> >> Testing(linux_x64): >> [+] test/hotspot/jtreg/runtime/cds >> [+] test/hotspot/jtreg/gc > > Yi Yang 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: > > CollectCLDClosure collects duplicated CLDs when dumping dynamic archive Hi, Yi The _loaded_cld is a global list, in this case it looks contain duplicated CLD in it. The duplication could from the thread run shutdown hook. Could you try if (!cld->is_unloading()) { cld->inc_keep_alive(); `+` if (!_loaded_cld->contains(cld)) { _loaded_cld->append(cld); `+` } } Please let us know if you can avoid the crash. ------------- PR: https://git.openjdk.java.net/jdk/pull/3320 From iklam at openjdk.java.net Sat Apr 3 01:45:31 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 3 Apr 2021 01:45:31 GMT Subject: RFR: 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive [v2] In-Reply-To: <0Xeiro7_nan2N7VDrDRuGY-dSDPpNALo4j6uXHpxmB4=.3be532fb-ac15-4dc0-a70a-a2a5c2b5b205@github.com> References: <0Xeiro7_nan2N7VDrDRuGY-dSDPpNALo4j6uXHpxmB4=.3be532fb-ac15-4dc0-a70a-a2a5c2b5b205@github.com> Message-ID: On Fri, 2 Apr 2021 10:21:56 GMT, Yi Yang wrote: >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/classfile/classLoaderData.cpp:316), pid=68929, tid=68930 >> # assert(_keep_alive > 0) failed: Invalid keep alive decrement count >> # >> # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.qingfengyy.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 17-internal+0-adhoc.qingfengyy.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 >> >> Stack: [0x00007f1593072000,0x00007f1593173000], sp=0x00007f1593171c00, free space=1023k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 >> V [libjvm.so+0xef19e7] MetaspaceShared::link_and_cleanup_shared_classes(Thread*)+0x181 >> V [libjvm.so+0x1260834] JavaThread::invoke_shutdown_hooks()+0x46 >> V [libjvm.so+0x12609e5] Threads::destroy_vm()+0xe7 >> V [libjvm.so+0xbb40ec] jni_DestroyJavaVM_inner+0x91 >> V [libjvm.so+0xbb4147] jni_DestroyJavaVM+0x1f >> C [libjli.so+0x4b4f] JavaMain+0xc61 >> C [libjli.so+0xad93] ThreadJavaMain+0x27 >> We observed VM crashed when dumping dynamic archive in a simple springboot application(See detailed content on JBS attachment). I did some investigations. In rare case, both of the following paths may be stepped on when dumping dynamic archive: >> >> 1. SIGINT >> at java.lang.Shutdown.beforeHalt(java.base at 17-internal/Native Method) >> at java.lang.Shutdown.exit(java.base at 17-internal/Shutdown.java:172) >> - locked <0x00000007fef02040> (a java.lang.Class for java.lang.Shutdown) >> at java.lang.Terminator$1.handle(java.base at 17-internal/Terminator.java:51) >> at jdk.internal.misc.Signal$1.run(java.base at 17-internal/Signal.java:219) >> at java.lang.Thread.run(java.base at 17-internal/Thread.java:831) >> >> 2. Normal Exit >> JavaThread::invoke_shutdown_hooks()+0x46 >> Threads::destroy_vm()+0xe7 >> jni_DestroyJavaVM_inner+0x91 >> jni_DestroyJavaVM+0x1f >> JavaMain+0xc61 >> ThreadJavaMain+0x27 >> >> They would call MetaspaceShared::link_and_cleanup_shared_classes, and CollectCLDClosure collects duplicated CLDs into _loaded_cld, _keep_alive is decrementing twice, causing a negative _keep_alive. >> >> Testing(linux_x64): >> [+] test/hotspot/jtreg/runtime/cds >> [+] test/hotspot/jtreg/gc > > Yi Yang 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: > > CollectCLDClosure collects duplicated CLDs when dumping dynamic archive The fix looks reasonable. If MetaspaceShared::link_and_cleanup_shared_classes may be called twice, it's better to isolate the loaded_cld for each invocation. Allocating it locally will also avoid any potential threading issues. I have some requests for cleaning up the code. src/hotspot/share/memory/metaspaceShared.cpp line 569: > 567: ResourceMark rm; > 568: GrowableArray loaded_cld; > 569: CollectCLDClosure collect_cld(&loaded_cld); I think we should add a comment to say why it's necessary to first collect the ClassLoaderDatas first: // ClassLoaderDataGraph::loaded_cld_do requires ClassLoaderDataGraph_lock. // We cannot link the classes while holding this lock (or else we may run into deadlock). // Therefore, we need to first collect all the CLDs, and then link their classes after // releasing the lock. src/hotspot/share/memory/metaspaceShared.cpp line 600: > 598: cld->dec_keep_alive(); > 599: } > 600: loaded_cld.trunc_to(0); There's no need for the trucate -- `loaded_cld` is locally allocated and will be freed after this function returns. Also, to improve modularity, I think we should move the dec_keep_alive loop into the destructor of CollectCLDClosure. Also, `loaded_cld` can be moved as a field into CollectCLDClosure. ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3320 From eosterlund at openjdk.java.net Sat Apr 3 14:55:26 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Sat, 3 Apr 2021 14:55:26 GMT Subject: RFR: 8264393: JDK-8258284 introduced dangling TLH race [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 01:57:40 GMT, Daniel D. Daugherty wrote: >> I ported some 20 year old tests using JDK-8262881 in order to help >> test [~rehn]'s fix for JDK-8257831. These tests in combination with >> one piece of the fix from JDK-8257831 revealed a bug in my fix for >> JDK-8258284 from back in Dec 2020. >> >> The race revealed by the ported tests from JDK-8262881 happens >> only with nested ThreadsListHandles. When TLH2 is destroyed, the >> thread updates its threads_hazard_ptr from the TLH2-list to the >> TLH1-list; I made this change back in 2020.12 using JDK-8258284. >> The threads_hazard_ptr can be observed by a thread calling >> ThreadsSMRSupport::free_list() as a stable ThreadsList at the same >> time as the TLH1 destructor is decrementing the nested_handle_cnt >> that permits the ThreadsList to be freed. So the thread calling >> ThreadsSMRSupport::free_list() thinks it has a stable hazard ptr >> (TLH1-list), but that hazard ptr can be freed and causes lots of >> confusion. >> >> Update: This fix along with the fix from JDK-8264123 were stress >> tested with the new tests from JDK-8262881. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR - fix nit in assert mesg. Not sure how I missed this race earlier. I never originally intended for hazard pointers to be set when exiting nested ThreadsListHandles. Anyway - the problem is understood and the fix looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3272 From dcubed at openjdk.java.net Sat Apr 3 19:05:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 3 Apr 2021 19:05:34 GMT Subject: RFR: 8264393: JDK-8258284 introduced dangling TLH race [v3] In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 14:52:29 GMT, Erik ?sterlund wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes CR - fix nit in assert mesg. > > Not sure how I missed this race earlier. I never originally intended for hazard pointers to be set when exiting nested ThreadsListHandles. Anyway - the problem is understood and the fix looks good. @fisk - Thanks for the review. The fault is mine from when I worked on JDK-8258284. I even added the new test that verified the improper behavior. In any case, it's fixed now and comments are added that should prevent any of us that play with this code from making the same mistake again. ------------- PR: https://git.openjdk.java.net/jdk/pull/3272 From dcubed at openjdk.java.net Sat Apr 3 19:06:30 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 3 Apr 2021 19:06:30 GMT Subject: Integrated: 8264123: add ThreadsList.is_valid() support In-Reply-To: References: Message-ID: <-lJYyfB71J2ZKYi_o1Z13ytz26D_Zk2lcIYxmFN1Y4k=.8058a6ab-14a9-4e5f-a77f-595b2c8157bd@github.com> On Mon, 29 Mar 2021 21:48:23 GMT, Daniel D. Daugherty wrote: > ThreadsLists need an is_valid() function and checks in various > places to help catch bugs where a ThreadsList is dangling. > > Other minor changes: > - change raw `_threads_hazard_ptr` access to used `get_threads_hazard_ptr()`. > - `get_threads_hazard_ptr()` should be `const`. > - fix a couple of old typos. > > Update: forgot to mention that this fix was tested with Mach5 Tier[1-8]. This pull request has now been integrated. Changeset: 9b2232bc Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/9b2232bc Stats: 60 lines in 4 files changed: 48 ins; 0 del; 12 mod 8264123: add ThreadsList.is_valid() support Reviewed-by: dholmes, eosterlund, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/3255 From dcubed at openjdk.java.net Sat Apr 3 19:10:30 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 3 Apr 2021 19:10:30 GMT Subject: Integrated: 8264393: JDK-8258284 introduced dangling TLH race In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 16:35:23 GMT, Daniel D. Daugherty wrote: > I ported some 20 year old tests using JDK-8262881 in order to help > test [~rehn]'s fix for JDK-8257831. These tests in combination with > one piece of the fix from JDK-8257831 revealed a bug in my fix for > JDK-8258284 from back in Dec 2020. > > The race revealed by the ported tests from JDK-8262881 happens > only with nested ThreadsListHandles. When TLH2 is destroyed, the > thread updates its threads_hazard_ptr from the TLH2-list to the > TLH1-list; I made this change back in 2020.12 using JDK-8258284. > The threads_hazard_ptr can be observed by a thread calling > ThreadsSMRSupport::free_list() as a stable ThreadsList at the same > time as the TLH1 destructor is decrementing the nested_handle_cnt > that permits the ThreadsList to be freed. So the thread calling > ThreadsSMRSupport::free_list() thinks it has a stable hazard ptr > (TLH1-list), but that hazard ptr can be freed and causes lots of > confusion. > > Update: This fix along with the fix from JDK-8264123 were stress > tested with the new tests from JDK-8262881. This pull request has now been integrated. Changeset: f259eeaf Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/f259eeaf Stats: 65 lines in 4 files changed: 22 ins; 21 del; 22 mod 8264393: JDK-8258284 introduced dangling TLH race Reviewed-by: dholmes, rehn, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/3272 From yyang at openjdk.java.net Mon Apr 5 03:48:03 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 5 Apr 2021 03:48:03 GMT Subject: RFR: 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive [v2] In-Reply-To: <3j2GXrtHpavIufN5v2QhkOGRUVyoBmvk3KmUKGpGAf0=.a230bd13-5e48-4465-b42c-1b6ea8ffb856@github.com> References: <0Xeiro7_nan2N7VDrDRuGY-dSDPpNALo4j6uXHpxmB4=.3be532fb-ac15-4dc0-a70a-a2a5c2b5b205@github.com> <3j2GXrtHpavIufN5v2QhkOGRUVyoBmvk3KmUKGpGAf0=.a230bd13-5e48-4465-b42c-1b6ea8ffb856@github.com> Message-ID: On Fri, 2 Apr 2021 21:55:20 GMT, Yumin Qi wrote: > Hi, Yi > The _loaded_cld is a global list, in this case it looks contain duplicated CLD in it. > The duplication could from the thread run shutdown hook. > Could you try > if (!cld->is_unloading()) { > cld->inc_keep_alive(); > `+` if (!_loaded_cld->contains(cld)) { > _loaded_cld->append(cld); > `+` } > } > Please let us know if you can avoid the crash. Hi Yumin, this fix still crashes because the CLDs collected at the first invocation of MetaspaceShared::link_and_cleanup_shared_classes are not cleaned, they will decrement their _keep_alives as before at the second invocation of MetaspaceShared::link_and_cleanup_shared_classes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3320 From yyang at openjdk.java.net Mon Apr 5 04:33:24 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 5 Apr 2021 04:33:24 GMT Subject: RFR: 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive [v3] In-Reply-To: References: Message-ID: > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/classfile/classLoaderData.cpp:316), pid=68929, tid=68930 > # assert(_keep_alive > 0) failed: Invalid keep alive decrement count > # > # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.qingfengyy.jdk) > # Java VM: OpenJDK 64-Bit Server VM (slowdebug 17-internal+0-adhoc.qingfengyy.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 > > Stack: [0x00007f1593072000,0x00007f1593173000], sp=0x00007f1593171c00, free space=1023k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 > V [libjvm.so+0xef19e7] MetaspaceShared::link_and_cleanup_shared_classes(Thread*)+0x181 > V [libjvm.so+0x1260834] JavaThread::invoke_shutdown_hooks()+0x46 > V [libjvm.so+0x12609e5] Threads::destroy_vm()+0xe7 > V [libjvm.so+0xbb40ec] jni_DestroyJavaVM_inner+0x91 > V [libjvm.so+0xbb4147] jni_DestroyJavaVM+0x1f > C [libjli.so+0x4b4f] JavaMain+0xc61 > C [libjli.so+0xad93] ThreadJavaMain+0x27 > We observed VM crashed when dumping dynamic archive in a simple springboot application(See detailed content on JBS attachment). I did some investigations. In rare case, both of the following paths may be stepped on when dumping dynamic archive: > > 1. SIGINT > at java.lang.Shutdown.beforeHalt(java.base at 17-internal/Native Method) > at java.lang.Shutdown.exit(java.base at 17-internal/Shutdown.java:172) > - locked <0x00000007fef02040> (a java.lang.Class for java.lang.Shutdown) > at java.lang.Terminator$1.handle(java.base at 17-internal/Terminator.java:51) > at jdk.internal.misc.Signal$1.run(java.base at 17-internal/Signal.java:219) > at java.lang.Thread.run(java.base at 17-internal/Thread.java:831) > > 2. Normal Exit > JavaThread::invoke_shutdown_hooks()+0x46 > Threads::destroy_vm()+0xe7 > jni_DestroyJavaVM_inner+0x91 > jni_DestroyJavaVM+0x1f > JavaMain+0xc61 > ThreadJavaMain+0x27 > > They would call MetaspaceShared::link_and_cleanup_shared_classes, and CollectCLDClosure collects duplicated CLDs into _loaded_cld, _keep_alive is decrementing twice, causing a negative _keep_alive. > > Testing(linux_x64): > [+] test/hotspot/jtreg/runtime/cds > [+] test/hotspot/jtreg/gc Yi Yang has updated the pull request incrementally with one additional commit since the last revision: improve modularity ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3320/files - new: https://git.openjdk.java.net/jdk/pull/3320/files/56a47fce..fea3c4b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3320&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3320&range=01-02 Stats: 26 lines in 1 file changed: 12 ins; 7 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3320/head:pull/3320 PR: https://git.openjdk.java.net/jdk/pull/3320 From yyang at openjdk.java.net Mon Apr 5 04:33:25 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 5 Apr 2021 04:33:25 GMT Subject: RFR: 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive [v2] In-Reply-To: References: <0Xeiro7_nan2N7VDrDRuGY-dSDPpNALo4j6uXHpxmB4=.3be532fb-ac15-4dc0-a70a-a2a5c2b5b205@github.com> <3j2GXrtHpavIufN5v2QhkOGRUVyoBmvk3KmUKGpGAf0=.a230bd13-5e48-4465-b42c-1b6ea8ffb856@github.com> Message-ID: On Mon, 5 Apr 2021 03:45:58 GMT, Yi Yang wrote: >> Hi, Yi >> The _loaded_cld is a global list, in this case it looks contain duplicated CLD in it. >> The duplication could from the thread run shutdown hook. >> Could you try >> if (!cld->is_unloading()) { >> cld->inc_keep_alive(); >> `+` if (!_loaded_cld->contains(cld)) { >> _loaded_cld->append(cld); >> `+` } >> } >> Please let us know if you can avoid the crash. > >> Hi, Yi >> The _loaded_cld is a global list, in this case it looks contain duplicated CLD in it. >> The duplication could from the thread run shutdown hook. >> Could you try >> if (!cld->is_unloading()) { >> cld->inc_keep_alive(); >> `+` if (!_loaded_cld->contains(cld)) { >> _loaded_cld->append(cld); >> `+` } >> } >> Please let us know if you can avoid the crash. > > Hi Yumin, this fix still crashes because the CLDs collected at the first invocation of MetaspaceShared::link_and_cleanup_shared_classes are not cleaned, they will decrement their _keep_alives as before at the second invocation of MetaspaceShared::link_and_cleanup_shared_classes. Hi Ioi, > Also, to improve modularity, I think we should move the dec_keep_alive loop into the destructor of CollectCLDClosure. > Also, loaded_cld can be moved as a field into CollectCLDClosure. Suggestions make sense, changed. Tests under runtime/cds/ are all passed with slowdebug mode. ------------- PR: https://git.openjdk.java.net/jdk/pull/3320 From iklam at openjdk.java.net Mon Apr 5 04:46:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 5 Apr 2021 04:46:56 GMT Subject: RFR: 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive [v3] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 04:33:24 GMT, Yi Yang wrote: >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/classfile/classLoaderData.cpp:316), pid=68929, tid=68930 >> # assert(_keep_alive > 0) failed: Invalid keep alive decrement count >> # >> # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.qingfengyy.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 17-internal+0-adhoc.qingfengyy.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 >> >> Stack: [0x00007f1593072000,0x00007f1593173000], sp=0x00007f1593171c00, free space=1023k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 >> V [libjvm.so+0xef19e7] MetaspaceShared::link_and_cleanup_shared_classes(Thread*)+0x181 >> V [libjvm.so+0x1260834] JavaThread::invoke_shutdown_hooks()+0x46 >> V [libjvm.so+0x12609e5] Threads::destroy_vm()+0xe7 >> V [libjvm.so+0xbb40ec] jni_DestroyJavaVM_inner+0x91 >> V [libjvm.so+0xbb4147] jni_DestroyJavaVM+0x1f >> C [libjli.so+0x4b4f] JavaMain+0xc61 >> C [libjli.so+0xad93] ThreadJavaMain+0x27 >> We observed VM crashed when dumping dynamic archive in a simple springboot application(See detailed content on JBS attachment). I did some investigations. In rare case, both of the following paths may be stepped on when dumping dynamic archive: >> >> 1. SIGINT >> at java.lang.Shutdown.beforeHalt(java.base at 17-internal/Native Method) >> at java.lang.Shutdown.exit(java.base at 17-internal/Shutdown.java:172) >> - locked <0x00000007fef02040> (a java.lang.Class for java.lang.Shutdown) >> at java.lang.Terminator$1.handle(java.base at 17-internal/Terminator.java:51) >> at jdk.internal.misc.Signal$1.run(java.base at 17-internal/Signal.java:219) >> at java.lang.Thread.run(java.base at 17-internal/Thread.java:831) >> >> 2. Normal Exit >> JavaThread::invoke_shutdown_hooks()+0x46 >> Threads::destroy_vm()+0xe7 >> jni_DestroyJavaVM_inner+0x91 >> jni_DestroyJavaVM+0x1f >> JavaMain+0xc61 >> ThreadJavaMain+0x27 >> >> They would call MetaspaceShared::link_and_cleanup_shared_classes, and CollectCLDClosure collects duplicated CLDs into _loaded_cld, _keep_alive is decrementing twice, causing a negative _keep_alive. >> >> Testing(linux_x64): >> [+] test/hotspot/jtreg/runtime/cds >> [+] test/hotspot/jtreg/gc > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > improve modularity Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3320 From yyang at openjdk.java.net Mon Apr 5 07:44:04 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 5 Apr 2021 07:44:04 GMT Subject: RFR: 8264682: MemProfiling does not own Heap_lock when using G1 Message-ID: Trivial fix for JDK-8264682. `Universe::heap()->used()` calls G1Allocator::used_in_alloc_regions() when G1 enabled, it checks whether Heap_lock was owned on this thread's behalf. ------------- Commit messages: - memprofiling_crash Changes: https://git.openjdk.java.net/jdk/pull/3340/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3340&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264682 Stats: 59 lines in 2 files changed: 59 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3340/head:pull/3340 PR: https://git.openjdk.java.net/jdk/pull/3340 From kbarrett at openjdk.java.net Mon Apr 5 14:31:24 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 5 Apr 2021 14:31:24 GMT Subject: RFR: 8264682: MemProfiling does not own Heap_lock when using G1 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 07:34:30 GMT, Yi Yang wrote: > Trivial fix for JDK-8264682. No, not trivial at all. Dropping a GC-specific blob like this into shared code is highly questionable. I'm not sure how this issue should be addressed, but I don't think the proposed change is the right approach. ------------- PR: https://git.openjdk.java.net/jdk/pull/3340 From minqi at openjdk.java.net Mon Apr 5 15:38:31 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 5 Apr 2021 15:38:31 GMT Subject: RFR: 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive [v3] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 04:33:24 GMT, Yi Yang wrote: >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/classfile/classLoaderData.cpp:316), pid=68929, tid=68930 >> # assert(_keep_alive > 0) failed: Invalid keep alive decrement count >> # >> # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.qingfengyy.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 17-internal+0-adhoc.qingfengyy.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 >> >> Stack: [0x00007f1593072000,0x00007f1593173000], sp=0x00007f1593171c00, free space=1023k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 >> V [libjvm.so+0xef19e7] MetaspaceShared::link_and_cleanup_shared_classes(Thread*)+0x181 >> V [libjvm.so+0x1260834] JavaThread::invoke_shutdown_hooks()+0x46 >> V [libjvm.so+0x12609e5] Threads::destroy_vm()+0xe7 >> V [libjvm.so+0xbb40ec] jni_DestroyJavaVM_inner+0x91 >> V [libjvm.so+0xbb4147] jni_DestroyJavaVM+0x1f >> C [libjli.so+0x4b4f] JavaMain+0xc61 >> C [libjli.so+0xad93] ThreadJavaMain+0x27 >> We observed VM crashed when dumping dynamic archive in a simple springboot application(See detailed content on JBS attachment). I did some investigations. In rare case, both of the following paths may be stepped on when dumping dynamic archive: >> >> 1. SIGINT >> at java.lang.Shutdown.beforeHalt(java.base at 17-internal/Native Method) >> at java.lang.Shutdown.exit(java.base at 17-internal/Shutdown.java:172) >> - locked <0x00000007fef02040> (a java.lang.Class for java.lang.Shutdown) >> at java.lang.Terminator$1.handle(java.base at 17-internal/Terminator.java:51) >> at jdk.internal.misc.Signal$1.run(java.base at 17-internal/Signal.java:219) >> at java.lang.Thread.run(java.base at 17-internal/Thread.java:831) >> >> 2. Normal Exit >> JavaThread::invoke_shutdown_hooks()+0x46 >> Threads::destroy_vm()+0xe7 >> jni_DestroyJavaVM_inner+0x91 >> jni_DestroyJavaVM+0x1f >> JavaMain+0xc61 >> ThreadJavaMain+0x27 >> >> They would call MetaspaceShared::link_and_cleanup_shared_classes, and CollectCLDClosure collects duplicated CLDs into _loaded_cld, _keep_alive is decrementing twice, causing a negative _keep_alive. >> >> Testing(linux_x64): >> [+] test/hotspot/jtreg/runtime/cds >> [+] test/hotspot/jtreg/gc > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > improve modularity Make the CLD list local is a reasonable solution. LGTM. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3320 From gziemski at openjdk.java.net Mon Apr 5 16:25:12 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 5 Apr 2021 16:25:12 GMT Subject: RFR: 8264482: container info misleads on non-container environment In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 00:05:40 GMT, Yasumasa Suenaga wrote: >> I removed container runtime detection code - this PR changes log / hs_err / VM.info message only at result. >> How about this? please review it. > > Commit 8fd9b3f95d40783ef3b70769ba0381f55df832a5 seems to fail on macOS x64 (hs/tier1 compiler) tests, but I think it is not caused by this change because I modified Linux code only. > Commit [8fd9b3f](https://github.com/openjdk/jdk/commit/8fd9b3f95d40783ef3b70769ba0381f55df832a5) seems to fail on macOS x64 (hs/tier1 compiler) tests, but I think it is not caused by this change because I modified Linux code only. I'll check it out on my local macOS machine and report back... ------------- PR: https://git.openjdk.java.net/jdk/pull/3280 From vlivanov at openjdk.java.net Mon Apr 5 17:52:30 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 5 Apr 2021 17:52:30 GMT Subject: RFR: 8264731: Introduce InstanceKlass::method_at_itable_or_null() Message-ID: Introduce `InstanceKlass::method_at_itable_or_null()` - a non-throwing variant of `InstanceKlass::method_at_itable()` that implements interface method selection. As a cleanup, rewrite `InstanceKlass::method_at_itable()` on top of `InstanceKlass::method_at_itable_or_null()`. Testing: * [x] hs-tier1 - hs-tier6 ------------- Commit messages: - InstanceKlass::method_at_itable_or_null Changes: https://git.openjdk.java.net/jdk/pull/3344/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3344&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264731 Stats: 46 lines in 3 files changed: 14 ins; 9 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/3344.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3344/head:pull/3344 PR: https://git.openjdk.java.net/jdk/pull/3344 From gziemski at openjdk.java.net Mon Apr 5 17:59:18 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 5 Apr 2021 17:59:18 GMT Subject: RFR: 8264482: container info misleads on non-container environment In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 16:22:13 GMT, Gerard Ziemski wrote: > > Commit [8fd9b3f](https://github.com/openjdk/jdk/commit/8fd9b3f95d40783ef3b70769ba0381f55df832a5) seems to fail on macOS x64 (hs/tier1 compiler) tests, but I think it is not caused by this change because I modified Linux code only. > > I'll check it out on my local macOS machine and report back... On my local mac with the latest jdk+PR3280 I see all tests pass: ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg:tier1_compiler 783 783 0 0 ============================== TEST SUCCESS ------------- PR: https://git.openjdk.java.net/jdk/pull/3280 From vlivanov at openjdk.java.net Mon Apr 5 18:12:37 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 5 Apr 2021 18:12:37 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() Message-ID: Turn `resolved_method` parameter into raw `Method*`. Testing: * [x] hs-tier1 - hs-tier6 ------------- Commit messages: - LinkResolver::vtable_index_of_interface_method Changes: https://git.openjdk.java.net/jdk/pull/3346/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3346&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264732 Stats: 7 lines in 3 files changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3346/head:pull/3346 PR: https://git.openjdk.java.net/jdk/pull/3346 From gziemski at openjdk.java.net Mon Apr 5 18:17:08 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 5 Apr 2021 18:17:08 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 13:23:44 GMT, Yasumasa Suenaga wrote: >> `jdk.CPUInformation` event on AArch64 has valid CPU description in [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491), however it does not work on UEFI booted machine. >> >> [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491) refers device tree to get board name, however it does not exist on UEFI. We need to refer DMI. >> However we need to have root privilege, so we refer /sys/devices/virtual/dmi/id to avoid it. >> >> We can get board name from /sys/devices/virtual/dmi/id/board_name, but some machine set empty string to it. So we will refer /sys/devices/virtual/dmi/id/product_name as a fallback. >> >> For example, we can get following CPU description on AWS A1 instance after this change: >> >> jdk.CPUInformation { >> startTime = 05:28:24.506 >> cpu = "AArch64" >> description = "AArch64 a1.2xlarge 0x41:0x0:0xd08:3, simd, crc, aes, sha1, sha256" >> sockets = 8 >> cores = 8 >> hwThreads = 8 >> } > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > refactoring 2 small nitpicks, but otherwise the functionality of the code looks good to me, though I will have to trust you on using the files to get the CPU description, since I'm no Linux expert: "/proc/device-tree/compatible", "/sys/devices/virtual/dmi/id/board_name", "/sys/devices/virtual/dmi/id/product_name" src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp line 174: > 172: assert(buf != NULL, "invalid argument"); > 173: assert(buflen >= 1, "invalid argument"); > 174: int fd = open(fname, O_RDONLY); Should be: ` int fd = os::open(fname, O_RDONLY);` src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp line 176: > 174: int fd = open(fname, O_RDONLY); > 175: if (fd != -1) { > 176: ssize_t read_sz = read(fd, buf, buflen); Should be: `ssize_t read_sz = os::read(fd, buf, buflen);` ------------- Changes requested by gziemski (Committer). PR: https://git.openjdk.java.net/jdk/pull/3259 From gziemski at openjdk.java.net Mon Apr 5 18:23:24 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 5 Apr 2021 18:23:24 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 13:23:44 GMT, Yasumasa Suenaga wrote: >> `jdk.CPUInformation` event on AArch64 has valid CPU description in [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491), however it does not work on UEFI booted machine. >> >> [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491) refers device tree to get board name, however it does not exist on UEFI. We need to refer DMI. >> However we need to have root privilege, so we refer /sys/devices/virtual/dmi/id to avoid it. >> >> We can get board name from /sys/devices/virtual/dmi/id/board_name, but some machine set empty string to it. So we will refer /sys/devices/virtual/dmi/id/product_name as a fallback. >> >> For example, we can get following CPU description on AWS A1 instance after this change: >> >> jdk.CPUInformation { >> startTime = 05:28:24.506 >> cpu = "AArch64" >> description = "AArch64 a1.2xlarge 0x41:0x0:0xd08:3, simd, crc, aes, sha1, sha256" >> sockets = 8 >> cores = 8 >> hwThreads = 8 >> } > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > refactoring src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp line 183: > 181: // (e.g. /sys/devices/virtual/dmi/id/board_name) > 182: if ((read_sz > 0) && (*buf != '\n')) { > 183: buf[read_sz - 1] = '\0'; Personally, I would move it after we process the characters. It logically belongs at the end of the processing code, just before we return "true". ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From lfoltan at openjdk.java.net Mon Apr 5 18:37:24 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 5 Apr 2021 18:37:24 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() In-Reply-To: References: Message-ID: <-ZEGGp13-OmRzPamNpW85GtV8wtxGO_8kIJiUuSZcUc=.606405ce-f18f-4ea3-b3fb-113d555c2bec@github.com> On Mon, 5 Apr 2021 18:01:15 GMT, Vladimir Ivanov wrote: > Turn `resolved_method` parameter into raw `Method*`. > > Testing: > * [x] hs-tier1 - hs-tier6 Looks good to me. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3346 From coleenp at openjdk.java.net Mon Apr 5 19:12:25 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 5 Apr 2021 19:12:25 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 18:01:15 GMT, Vladimir Ivanov wrote: > Turn `resolved_method` parameter into raw `Method*`. > > Testing: > * [x] hs-tier1 - hs-tier6 src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 731: > 729: C2V_VMENTRY_0(jint, getVtableIndexForInterfaceMethod, (JNIEnv* env, jobject, jobject jvmci_type, jobject jvmci_method)) > 730: Klass* klass = JVMCIENV->asKlass(jvmci_type); > 731: Method* method = JVMCIENV->asMethod(jvmci_method); The reason that resolved_method was a methodHandle is in case of redefinition, we need to know if code is referring to this version of the method so that it's not deallocated. It's enough for one of the callers to create a methodHandle but passing the methodHandle will guarantee it. I'm not sure why you needed to make this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/3346 From iklam at openjdk.java.net Mon Apr 5 22:02:42 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 5 Apr 2021 22:02:42 GMT Subject: RFR: 8214455: Relocate CDS archived regions to the top of the G1 heap Message-ID: When the runtime heap and dump time heap have different sizes, it's possible that the archived heap regions are mapped to the middle of the runtime heap. Because the archived heap regions are pinned, this could reduce the size of the largest "humongous" array allocation. In the worst case, the maximum allocatable array length may be half of the optimal value. The fix is to relocate the archived regions to the top of the G1 heap (currently archived regions are supported only by G1 on 64-bit JVM). Note that usually the top of the G1 heap is placed just below the 32GB boundary. As a result, the archived heap regions are at the same location between run time and dump time, so no relocation is necessary. In mach5 testing, we occasionally run into this problem (see https://bugs.openjdk.java.net/browse/JDK-8239089), probably because we fail to reserve the heap below 32GB due to address space layout randomization (ASLR). ------------- Commit messages: - Added -Xlog:cds=debug in case this test fails again - 8214455: Relocate CDS archived regions to the top of the G1 heap Changes: https://git.openjdk.java.net/jdk/pull/3349/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3349&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8214455 Stats: 143 lines in 8 files changed: 139 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3349/head:pull/3349 PR: https://git.openjdk.java.net/jdk/pull/3349 From iklam at openjdk.java.net Mon Apr 5 22:48:25 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 5 Apr 2021 22:48:25 GMT Subject: RFR: 8264682: MemProfiling does not own Heap_lock when using G1 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 14:29:11 GMT, Kim Barrett wrote: > > Trivial fix for JDK-8264682. > > No, not trivial at all. Dropping a GC-specific blob like this into shared code is highly questionable. I'm not sure how this issue should be addressed, but I don't think the proposed change is the right approach. It looks like the following APIs can be reliably called without holding the Heap_lock. However, I am not sure if they would give the same result. I.e., can you get `Universe::heap()->unused()` by calling `Universe::heap()->capacity() - Universe::heap()->unused()`. JVM_ENTRY_NO_ENV(jlong, JVM_TotalMemory(void)) size_t n = Universe::heap()->capacity(); return convert_size_t_to_jlong(n); JVM_END JVM_ENTRY_NO_ENV(jlong, JVM_FreeMemory(void)) size_t n = Universe::heap()->unused(); return convert_size_t_to_jlong(n); JVM_END ------------- PR: https://git.openjdk.java.net/jdk/pull/3340 From ysuenaga at openjdk.java.net Mon Apr 5 23:52:17 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 5 Apr 2021 23:52:17 GMT Subject: RFR: 8264482: container info misleads on non-container environment In-Reply-To: References: Message-ID: <6ChRyYfJScngd_G9O0JZ8eBR1pEyzTFbgB2S2K0Crks=.1501e834-8c27-40ec-b330-e8e1e6f90559@github.com> On Mon, 5 Apr 2021 17:56:35 GMT, Gerard Ziemski wrote: >>> Commit [8fd9b3f](https://github.com/openjdk/jdk/commit/8fd9b3f95d40783ef3b70769ba0381f55df832a5) seems to fail on macOS x64 (hs/tier1 compiler) tests, but I think it is not caused by this change because I modified Linux code only. >> >> I'll check it out on my local macOS machine and report back... > >> > Commit [8fd9b3f](https://github.com/openjdk/jdk/commit/8fd9b3f95d40783ef3b70769ba0381f55df832a5) seems to fail on macOS x64 (hs/tier1 compiler) tests, but I think it is not caused by this change because I modified Linux code only. >> >> I'll check it out on my local macOS machine and report back... > > On my local mac with the latest jdk+PR3280 I see all tests pass: > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg:tier1_compiler 783 783 0 0 > ============================== > TEST SUCCESS Thanks @gerard-ziemski ! I'm waiting for reviewers... ------------- PR: https://git.openjdk.java.net/jdk/pull/3280 From ysuenaga at openjdk.java.net Tue Apr 6 01:22:48 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 6 Apr 2021 01:22:48 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v3] In-Reply-To: References: Message-ID: <07xszQhnfsbFlftK7fHgoFGVRhG9m_IPPUOg1-j120M=.7ae018d5-227e-448a-ad13-913c1ecd2ff1@github.com> > `jdk.CPUInformation` event on AArch64 has valid CPU description in [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491), however it does not work on UEFI booted machine. > > [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491) refers device tree to get board name, however it does not exist on UEFI. We need to refer DMI. > However we need to have root privilege, so we refer /sys/devices/virtual/dmi/id to avoid it. > > We can get board name from /sys/devices/virtual/dmi/id/board_name, but some machine set empty string to it. So we will refer /sys/devices/virtual/dmi/id/product_name as a fallback. > > For example, we can get following CPU description on AWS A1 instance after this change: > > jdk.CPUInformation { > startTime = 05:28:24.506 > cpu = "AArch64" > description = "AArch64 a1.2xlarge 0x41:0x0:0xd08:3, simd, crc, aes, sha1, sha256" > sockets = 8 > cores = 8 > hwThreads = 8 > } Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Use functions in os class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3259/files - new: https://git.openjdk.java.net/jdk/pull/3259/files/cb413927..e5b75dc5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3259&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3259&range=01-02 Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3259.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3259/head:pull/3259 PR: https://git.openjdk.java.net/jdk/pull/3259 From ysuenaga at openjdk.java.net Tue Apr 6 01:25:24 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 6 Apr 2021 01:25:24 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v2] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 18:14:44 GMT, Gerard Ziemski wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> refactoring > > 2 small nitpicks, but otherwise the functionality of the code looks good to me, though I will have to trust you on using the files to get the CPU description, since I'm no Linux expert: > > "/proc/device-tree/compatible", > "/sys/devices/virtual/dmi/id/board_name", > "/sys/devices/virtual/dmi/id/product_name" Thanks @gerard-ziemski for the comment! I used `os::open()`, `os::read()`, and `os::close()` in new commit. And also I moved `buf[read_sz - 1]` to just before `return true`. > 2 small nitpicks, but otherwise the functionality of the code looks good to me, though I will have to trust you on using the files to get the CPU description, since I'm no Linux expert: > > ``` > "/proc/device-tree/compatible", > "/sys/devices/virtual/dmi/id/board_name", > "/sys/devices/virtual/dmi/id/product_name" > ``` They are suggested in https://github.com/openjdk/jdk/pull/2759#issuecomment-789391247 ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From dholmes at openjdk.java.net Tue Apr 6 01:42:29 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Apr 2021 01:42:29 GMT Subject: RFR: 8264482: container info misleads on non-container environment [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 13:03:50 GMT, Yasumasa Suenaga wrote: >> hs_err log and `VM.info` dcmd shows cgroup information as container information even though the process run on non-container environment as following. >> >> container (cgroup) information: >> container_type: cgroupv2 >> cpu_cpuset_cpus: not supported >> cpu_memory_nodes: not supported >> active_processor_count: 4 >> cpu_quota: not supported >> cpu_period: not supported >> cpu_shares: not supported >> memory_limit_in_bytes: unlimited >> memory_and_swap_limit_in_bytes: unlimited >> memory_soft_limit_in_bytes: unlimited >> memory_usage_in_bytes: 164163584 >> memory_max_usage_in_bytes: not supported >> >> We can use cgroup outside of container, so it is useful to show. However cgroup is different from container. We should distinguish them. >> And also it is useful if we can see container runtime in this section. So I added it. We can see following contents in this section after this change. >> >> cgroup information: >> cgroup_type: cgroupv2 >> container runtime: podman >> cpu_cpuset_cpus: not supported >> cpu_memory_nodes: not supported >> active_processor_count: 4 >> cpu_quota: not supported >> cpu_period: not supported >> cpu_shares: not supported >> memory_limit_in_bytes: unlimited >> memory_and_swap_limit_in_bytes: unlimited >> memory_soft_limit_in_bytes: unlimited >> memory_usage_in_bytes: 256176128 >> memory_max_usage_in_bytes: not supported >> >> In case of systemd, it checks PID (PID 1 or not) and `$container` in PID 1. We should check them to know the JVM runs on the container or not. >> >> https://github.com/systemd/systemd/blob/68337e55f62cf49b7bdfb73dc5662e23b0ea17fa/src/basic/virt.c#L619 > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Remove code to detect container runtime Sorry Yasumasa but I don't agree with this. OSContainer is supposed to be the abstraction representing a containerized environment. Calling code doesn't know (nor care) what the underlying mechanism is - maybe it is cgroups, maybe it isn't. If there is an issue with reporting this stuff when not actually in a container then the fault lies in is_containerized() IMHO. David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3280 From coleenp at openjdk.java.net Tue Apr 6 02:05:23 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 6 Apr 2021 02:05:23 GMT Subject: RFR: 8264731: Introduce InstanceKlass::method_at_itable_or_null() In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 17:40:58 GMT, Vladimir Ivanov wrote: > Introduce `InstanceKlass::method_at_itable_or_null()` - a non-throwing variant of `InstanceKlass::method_at_itable()` that implements interface method selection. > > As a cleanup, rewrite `InstanceKlass::method_at_itable()` on top of `InstanceKlass::method_at_itable_or_null()`. > > Testing: > * [x] hs-tier1 - hs-tier6 This is a lot clearer than existing code. I don't see the caller other than mehod_at_itable() though. src/hotspot/share/oops/instanceKlass.cpp line 3179: > 3177: > 3178: Method* InstanceKlass::method_at_itable_or_null(InstanceKlass* holder, int index, bool& itable_entry_found) { > 3179: klassItable itable(this); I think you need a ResourceMark before this. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3344 From dholmes at openjdk.java.net Tue Apr 6 02:08:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Apr 2021 02:08:36 GMT Subject: RFR: 8264682: MemProfiling does not own Heap_lock when using G1 In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 07:34:30 GMT, Yi Yang wrote: > Trivial fix for JDK-8264682. > > `Universe::heap()->used()` calls G1Allocator::used_in_alloc_regions() when G1 enabled, it checks whether Heap_lock was owned on this thread's behalf. Sorry but I have to agree with Kim that this is the wrong fix for this problem. And the test needs adjusting. Thanks, David src/hotspot/share/runtime/memprofiler.cpp line 120: > 118: // used() calls G1Allocator::used_in_alloc_regions() when G1 enabled, > 119: // it checks whether Heap_lock was owned on this thread's behalf. > 120: G1GC_ONLY(MutexLocker ml(Heap_lock);) This seems really out of place - this code should not need to know anything about the specific locking requirements of different GC's. That should be handled inside the appropriate chunk of GC code. test/hotspot/jtreg/runtime/MemProfiler/MemProfilingWithGC.java line 44: > 42: "UseShenandoahGC", > 43: "UseZGC", > 44: "UseEpsilonGC", You have to allow for the fact that these GC's may not have all been built into the JVM under test. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3340 From yyang at openjdk.java.net Tue Apr 6 02:13:23 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 6 Apr 2021 02:13:23 GMT Subject: RFR: 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive [v3] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 15:35:11 GMT, Yumin Qi wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> improve modularity > > Make the CLD list local is a reasonable solution. LGTM. Thanks @yminqi @iklam for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3320 From ysuenaga at openjdk.java.net Tue Apr 6 02:31:24 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 6 Apr 2021 02:31:24 GMT Subject: RFR: 8264482: container info misleads on non-container environment [v2] In-Reply-To: References: Message-ID: <3xBZarV2-nFsRCB-iCLzNSE4H316QbfeZ61MHywMV9E=.215d64c5-1ad2-41df-926d-10941b734b3b@github.com> On Tue, 6 Apr 2021 01:38:50 GMT, David Holmes wrote: > If there is an issue with reporting this stuff when not actually in a container then the fault lies in is_containerized() IMHO. To resolve this problem, I think [JDK-8261242](https://bugs.openjdk.java.net/browse/JDK-8261242) is filed. But the discussion does not seem to active... it might take a lot of time to fix because there might not be clear solution to detect the process runs on the container. As I said in before, I want to remove "container" from log output because it makes to mislead. Especially next JDK release is LTS, so the code will use a long time. As an option, we can move logging code into `CgroupSubsystem`, but it might not be better... ------------- PR: https://git.openjdk.java.net/jdk/pull/3280 From dholmes at openjdk.java.net Tue Apr 6 02:56:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Apr 2021 02:56:31 GMT Subject: RFR: 8264731: Introduce InstanceKlass::method_at_itable_or_null() In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 17:40:58 GMT, Vladimir Ivanov wrote: > Introduce `InstanceKlass::method_at_itable_or_null()` - a non-throwing variant of `InstanceKlass::method_at_itable()` that implements interface method selection. > > As a cleanup, rewrite `InstanceKlass::method_at_itable()` on top of `InstanceKlass::method_at_itable_or_null()`. > > Testing: > * [x] hs-tier1 - hs-tier6 Hi Vladimir, Seems okay in principle. I assume more callers of the new API are in the pipeline? I have one suggested changed that would have made the code much much clearer to me. Thanks, David src/hotspot/share/oops/instanceKlass.cpp line 3154: > 3152: > 3153: Method* InstanceKlass::method_at_itable(InstanceKlass* holder, int index, TRAPS) { > 3154: bool itable_entry_found; // out parameter I was very confused about the logic in this code until I realized that itable_entry_found is actually an indicator as to whether or not the current class implements the interface represented by holder, and not an indicator of whether or not a method was found. It would be much clearer to me if this variable were renamed something like implements_interface. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3344 From yyang at openjdk.java.net Tue Apr 6 03:01:23 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 6 Apr 2021 03:01:23 GMT Subject: Integrated: 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 08:15:38 GMT, Yi Yang wrote: > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/qingfeng.yy/openjdk16_so_warning/jdk/src/hotspot/share/classfile/classLoaderData.cpp:316), pid=68929, tid=68930 > # assert(_keep_alive > 0) failed: Invalid keep alive decrement count > # > # JRE version: OpenJDK Runtime Environment (17.0) (slowdebug build 17-internal+0-adhoc.qingfengyy.jdk) > # Java VM: OpenJDK 64-Bit Server VM (slowdebug 17-internal+0-adhoc.qingfengyy.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 > > Stack: [0x00007f1593072000,0x00007f1593173000], sp=0x00007f1593171c00, free space=1023k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x781087] ClassLoaderData::dec_keep_alive()+0x31 > V [libjvm.so+0xef19e7] MetaspaceShared::link_and_cleanup_shared_classes(Thread*)+0x181 > V [libjvm.so+0x1260834] JavaThread::invoke_shutdown_hooks()+0x46 > V [libjvm.so+0x12609e5] Threads::destroy_vm()+0xe7 > V [libjvm.so+0xbb40ec] jni_DestroyJavaVM_inner+0x91 > V [libjvm.so+0xbb4147] jni_DestroyJavaVM+0x1f > C [libjli.so+0x4b4f] JavaMain+0xc61 > C [libjli.so+0xad93] ThreadJavaMain+0x27 > We observed VM crashed when dumping dynamic archive in a simple springboot application(See detailed content on JBS attachment). I did some investigations. In rare case, both of the following paths may be stepped on when dumping dynamic archive: > > 1. SIGINT > at java.lang.Shutdown.beforeHalt(java.base at 17-internal/Native Method) > at java.lang.Shutdown.exit(java.base at 17-internal/Shutdown.java:172) > - locked <0x00000007fef02040> (a java.lang.Class for java.lang.Shutdown) > at java.lang.Terminator$1.handle(java.base at 17-internal/Terminator.java:51) > at jdk.internal.misc.Signal$1.run(java.base at 17-internal/Signal.java:219) > at java.lang.Thread.run(java.base at 17-internal/Thread.java:831) > > 2. Normal Exit > JavaThread::invoke_shutdown_hooks()+0x46 > Threads::destroy_vm()+0xe7 > jni_DestroyJavaVM_inner+0x91 > jni_DestroyJavaVM+0x1f > JavaMain+0xc61 > ThreadJavaMain+0x27 > > They would call MetaspaceShared::link_and_cleanup_shared_classes, and CollectCLDClosure collects duplicated CLDs into _loaded_cld, _keep_alive is decrementing twice, causing a negative _keep_alive. > > Testing(linux_x64): > [+] test/hotspot/jtreg/runtime/cds > [+] test/hotspot/jtreg/gc This pull request has now been integrated. Changeset: 54b4070d Author: Yi Yang Committer: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/54b4070d Stats: 27 lines in 1 file changed: 14 ins; 7 del; 6 mod 8264634: CollectCLDClosure collects duplicated CLDs when dumping dynamic archive Reviewed-by: minqi, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3320 From david.holmes at oracle.com Tue Apr 6 03:05:18 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Apr 2021 13:05:18 +1000 Subject: RFR: 8264482: container info misleads on non-container environment [v2] In-Reply-To: <3xBZarV2-nFsRCB-iCLzNSE4H316QbfeZ61MHywMV9E=.215d64c5-1ad2-41df-926d-10941b734b3b@github.com> References: <3xBZarV2-nFsRCB-iCLzNSE4H316QbfeZ61MHywMV9E=.215d64c5-1ad2-41df-926d-10941b734b3b@github.com> Message-ID: <52c26968-23f2-bde1-0ee7-0085cc2c1c0c@oracle.com> On 6/04/2021 12:31 pm, Yasumasa Suenaga wrote: > On Tue, 6 Apr 2021 01:38:50 GMT, David Holmes wrote: > >> If there is an issue with reporting this stuff when not actually in a container then the fault lies in is_containerized() IMHO. > > To resolve this problem, I think [JDK-8261242](https://bugs.openjdk.java.net/browse/JDK-8261242) is filed. But the discussion does not seem to active... it might take a lot of time to fix because there might not be clear solution to detect the process runs on the container. > > As I said in before, I want to remove "container" from log output because it makes to mislead. Especially next JDK release is LTS, so the code will use a long time. > As an option, we can move logging code into `CgroupSubsystem`, but it might not be better... If you are actually running under a cgroup and have resource limits applied then aren't you effectively running in a "container"? its just not a container that has been productized like Docker et al. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3280 > From ysuenaga at openjdk.java.net Tue Apr 6 03:30:25 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 6 Apr 2021 03:30:25 GMT Subject: RFR: 8264482: container info misleads on non-container environment [v2] In-Reply-To: <3xBZarV2-nFsRCB-iCLzNSE4H316QbfeZ61MHywMV9E=.215d64c5-1ad2-41df-926d-10941b734b3b@github.com> References: <3xBZarV2-nFsRCB-iCLzNSE4H316QbfeZ61MHywMV9E=.215d64c5-1ad2-41df-926d-10941b734b3b@github.com> Message-ID: On Tue, 6 Apr 2021 02:28:46 GMT, Yasumasa Suenaga wrote: >> Sorry Yasumasa but I don't agree with this. OSContainer is supposed to be the abstraction representing a containerized environment. Calling code doesn't know (nor care) what the underlying mechanism is - maybe it is cgroups, maybe it isn't. If there is an issue with reporting this stuff when not actually in a container then the fault lies in is_containerized() IMHO. >> >> David > >> If there is an issue with reporting this stuff when not actually in a container then the fault lies in is_containerized() IMHO. > > To resolve this problem, I think [JDK-8261242](https://bugs.openjdk.java.net/browse/JDK-8261242) is filed. But the discussion does not seem to active... it might take a lot of time to fix because there might not be clear solution to detect the process runs on the container. > > As I said in before, I want to remove "container" from log output because it makes to mislead. Especially next JDK release is LTS, so the code will use a long time. > As an option, we can move logging code into `CgroupSubsystem`, but it might not be better... > If you are actually running under a cgroup and have resource limits > applied then aren't you effectively running in a "container"? No, we can see container logs even if the process is not limited by cgroups. I (and maybe JDK-8261242) want to say it is a problem. HotSpot detects whether it is run on container in following code. It checks whether specified directories exist. https://github.com/openjdk/jdk/blob/54b4070da76e79597a57412a39b85660dc49ce7c/src/hotspot/os/linux/cgroupSubsystem_linux.cpp#L44-L48 According to [cgoups manpage](https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES), `/proc/cgroups` seems to generated by kernel, so we cannot use them to detect. I think we should fix like systemd, and JDK-8261242 has been discussed on to do so. ------------- PR: https://git.openjdk.java.net/jdk/pull/3280 From xliu at openjdk.java.net Tue Apr 6 04:11:48 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 6 Apr 2021 04:11:48 GMT Subject: RFR: 8264742: member variable _monitor of MonitorLocker is redundant Message-ID: MonitorLocker is a subclass of MutexLocker. The member variable _monitor has the same value of _mutex in its base class. ------------- Commit messages: - member variable _monitor of MonitorLocker is redundant Changes: https://git.openjdk.java.net/jdk/pull/3350/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3350&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264742 Stats: 15 lines in 1 file changed: 5 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3350.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3350/head:pull/3350 PR: https://git.openjdk.java.net/jdk/pull/3350 From david.holmes at oracle.com Tue Apr 6 04:23:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Apr 2021 14:23:03 +1000 Subject: RFR: 8264742: member variable _monitor of MonitorLocker is redundant In-Reply-To: References: Message-ID: <17fe126f-7a9b-c909-1537-cc3bdb789cb7@oracle.com> Hi Xin, On 6/04/2021 2:11 pm, Xin Liu wrote: > MonitorLocker is a subclass of MutexLocker. The member variable _monitor > has the same value of _mutex in its base class. Yes it does, but it has a different type obviously. Do your as_monitor calls actually get completely elided by the compiler? If so then this change seems okay, but otherwise I prefer to save any runtime overhead by using an extra word of stack. Thanks, David > ------------- > > Commit messages: > - member variable _monitor of MonitorLocker is redundant > > Changes: https://git.openjdk.java.net/jdk/pull/3350/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3350&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8264742 > Stats: 15 lines in 1 file changed: 5 ins; 1 del; 9 mod > Patch: https://git.openjdk.java.net/jdk/pull/3350.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/3350/head:pull/3350 > > PR: https://git.openjdk.java.net/jdk/pull/3350 > From rehn at openjdk.java.net Tue Apr 6 07:33:20 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 07:33:20 GMT Subject: RFR: 8264393: JDK-8258284 introduced dangling TLH race [v3] In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 14:52:29 GMT, Erik ?sterlund wrote: > Not sure how I missed this race earlier. I never originally intended for hazard pointers to be set when exiting nested ThreadsListHandles. Anyway - the problem is understood and the fix looks good. I don't think you did, because originally we never intended them to be nested. I still feel that the simple solution to nesting: pausing deletion on nesting, thus never changing the hazard pointer would be better (as in much simpler). The only drawback is if there is a pathological case were we always have one thread with nested ThreadsLists (but hard to imagine). ------------- PR: https://git.openjdk.java.net/jdk/pull/3272 From xxinliu at amazon.com Tue Apr 6 07:55:24 2021 From: xxinliu at amazon.com (Liu, Xin) Date: Tue, 6 Apr 2021 07:55:24 +0000 Subject: RFR: 8264742: member variable _monitor of MonitorLocker is redundant In-Reply-To: <17fe126f-7a9b-c909-1537-cc3bdb789cb7@oracle.com> References: <17fe126f-7a9b-c909-1537-cc3bdb789cb7@oracle.com> Message-ID: <8B4DD65D-7CA7-49D4-BFC5-086C618E4A90@amazon.com> Hi, David, Yes, as_monitor() gets completely elided by gcc. I inspect function VMThread::wait_for_vm_thread_exit() as a sample. In release build, all member functions of MonitorLocker are successfully inlined by GCC 10.2.1. The code is exactly same as before. It's because optimizing compiler can perform redundant store elimination with alias analysis. I don't think this PR will help much on performance in release binaries if they built by GCC/LLVM. In fast-debug build, as_monitor() is inlined and deleted. A ctor MonitorLocker(Monitor*, Mutex::SafepointCheckFlag) isn't inlined. I compared the generated code. The code size reduces from 272 bytes to 238 in x86. After applying my patch, this ctor can save 1 caller-saved register and a store instruction which is generated from _monitor. I have uploaded comparison to https://bugs.openjdk.java.net/browse/JDK-8264742. Conclusion: as_monitor() doesn't bring extra cost. Lacking of aggressive compiler optimizations, this patch can save one machine-word on stack and a store for each MonitorLocker object. At least, it can bring a little bit performance for debug builds. Thanks, --lx ?On 4/5/21, 9:24 PM, "David Holmes" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Xin, On 6/04/2021 2:11 pm, Xin Liu wrote: > MonitorLocker is a subclass of MutexLocker. The member variable _monitor > has the same value of _mutex in its base class. Yes it does, but it has a different type obviously. Do your as_monitor calls actually get completely elided by the compiler? If so then this change seems okay, but otherwise I prefer to save any runtime overhead by using an extra word of stack. Thanks, David > ------------- > > Commit messages: > - member variable _monitor of MonitorLocker is redundant > > Changes: https://git.openjdk.java.net/jdk/pull/3350/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3350&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8264742 > Stats: 15 lines in 1 file changed: 5 ins; 1 del; 9 mod > Patch: https://git.openjdk.java.net/jdk/pull/3350.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/3350/head:pull/3350 > > PR: https://git.openjdk.java.net/jdk/pull/3350 > From rehn at openjdk.java.net Tue Apr 6 09:08:31 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 09:08:31 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: <3hnHTIU7h2VZ8ZcubYBQV7L-T8yyoJ1VUdQH5RK8eWE=.afc11483-37d2-4cc6-9177-13c6cb709e88@github.com> Message-ID: On Wed, 31 Mar 2021 14:32:23 GMT, Robbin Ehn wrote: >> SR_handler is used for OS-level suspend/resume (not to conflict with this change-set). >> This feature is only used by JFR (AFAIK), and JFR only samples threads on it's ThreadsList. >> This means the JavaThread can never be terminated, hence this code will always pass. >> >> If someone else is using OS-level suspend/resume without a ThreadsList, the bug is there is no ThreadsList AFAICT. >> >> Since ThreadLocalStorage::thread() is cleared last in ~Thread with Thread::clear_thread_current(); may be in the ~Thread destructor. >> So the argument is that would be safe to read stuff from Thread but not JavaThread? >> Since the compiler (and CPU) may reorder and optimize away code, so I argue reading from a half destroyed object is not a great idea. >> E.g. Monitor* _SR_lock; is not a volatile pointer; since reading from this memory is UB after destruction, compiler is free to remove or not publish the store to NULL. >> >> So I suggest either to remove this check, since the only user is using a ThreadsList and any other should also be using that too. >> Or call Thread::clear_thread_current() before the JavaThread destructor is called, that way we can be certain that there is no UB. > > I got some offline input from David, there seem to be an issue with signal being delivered after the ThreadsListHandle destructor. If that is the case a ThreadsList doesn't help here. > > So I suggested we keep this out of this change-set and just take another suitable field to mirror what we have today. > > `ParkEvent * _ParkEvent;` ? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 09:08:32 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 09:08:32 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 13:38:59 GMT, Richard Reingruber wrote: >> src/hotspot/share/runtime/handshake.cpp line 617: >> >>> 615: { >>> 616: MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); >>> 617: if (!is_suspend_requested()) { >> >> The current thread is _thread_in_vm. Can it be suspended then? For a suspend it has to be in a safe thread state which it cannot leave while suspended. So it must have reached _thread_in_vm not suspended and it cannot be suspended while in that state. > > Shouldn't `is_suspend_requested()` be replaced with `is_suspended()`? See also comment on declaration of `_suspend_requested`. Your are right. Doing a different version. Need some testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 09:31:34 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 09:31:34 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 13:28: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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.cpp line 715: > >> 713: bool HandshakeState::resume() { >> 714: // Can't be suspended if there is no suspend request. >> 715: if (!is_suspend_requested()) { > > Shouldn't `is_suspend_requested()` be replaced with `is_suspended()`? See also comment on declaration of `_suspend_requested`. Fixed > src/hotspot/share/runtime/handshake.cpp line 720: > >> 718: MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); >> 719: // Can't be suspended if there is no suspend request. >> 720: if (!is_suspend_requested()) { > > Shouldn't `is_suspend_requested()` be replaced with `is_suspended()`? See also comment on declaration of `_suspend_requested`. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 09:31:35 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 09:31:35 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 03:21:31 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/handshake.hpp line 142: >> >>> 140: private: >>> 141: volatile bool _suspended; >>> 142: volatile bool _suspend_requested; >> >> According to the PR description `_suspend_requested` is an optimization. >> >>> The "suspend requested" flag is an optimization, without it a dormant thread >>> could be suspended and resumed many times and each would add a new >>> asynchronous handshake. Suspend requested flag means there is already an >>> asynchronous suspend handshake in queue which can be re-used, only the suspend >>> flag needs to be set. >> >> I think there are a few places where _suspend_requested is queried by mistake instead of _suspended. Maybe it would help to prevent this if _suspend_requested was renamed to something that better describes its purpose, e.g. _has_async_suspend_handshake or similar. > > I also think it would be a good idea to rename it with something along those lines. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From sgehwolf at openjdk.java.net Tue Apr 6 09:43:26 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 6 Apr 2021 09:43:26 GMT Subject: RFR: 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to swapping not working [v2] In-Reply-To: <2QcFEnqjBIO1DIk7JmObayDiCVH9cvmyHOIZVrpznDY=.f3abf768-3a06-4525-9c36-3b2ba39a2e2a@github.com> References: <2QcFEnqjBIO1DIk7JmObayDiCVH9cvmyHOIZVrpznDY=.f3abf768-3a06-4525-9c36-3b2ba39a2e2a@github.com> Message-ID: On Fri, 2 Apr 2021 04:10:47 GMT, Jie Fu wrote: >> Hi @jerboaa , >> >> After more thinking, I think the reason why memory.failcnt is always 0 is that there is no swap space on the host machine. >> So the testMemoryFailCount should be skipped in that case. >> >> But is there any API which can be used to get the swap space size of the host machine? >> >> Thanks. > >> Consider a broken implementation of `Metrics.systemMetrics().getMemoryFailCount()`. Wouldn't the test now (falsely) pass? > > Hi @jerboaa , > > A pre-test run has been added to check whether swapping really works for testMemoryFailCount. > Swapping should be OK for memory.failcnt testing otherwise it will fail due to OOM killed. > > What do you think? > Thanks. @DamonFool Hmm, if swap not working is the issue the test shouldn't enter the branch which you say is failing. From `MetricsMemoryTester.java`: private static void testMemoryFailCount() { long memAndSwapLimit = Metrics.systemMetrics().getMemoryAndSwapLimit(); long memLimit = Metrics.systemMetrics().getMemoryLimit(); // We need swap to execute this test or will SEGV if (memAndSwapLimit <= memLimit) { // <=============== This is checking whether or not swap works System.out.println("No swap memory limits, test case skipped"); } else { It has been added with JDK-8250984. So now I'm even more confused what's going on here... ------------- PR: https://git.openjdk.java.net/jdk/pull/3286 From rehn at openjdk.java.net Tue Apr 6 09:43:24 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 09:43:24 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <7YguEQOtYiRSePMc_LMqRge_hC82d6W5YFRC3e4hnK0=.b4a7b678-a20b-4089-8a0c-4ed9a2e368b1@github.com> On Tue, 30 Mar 2021 13:36:17 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 323: > >> 321: // Suspend request flag can only be set in handshakes. >> 322: // By blocking handshakes, suspend request flag cannot change its value. >> 323: if (!jt->handshake_state()->is_suspend_requested()) { > > Shouldn't `jt->handshake_state()->is_suspend_requested()` be replaced with `jt->is_suspended()`? See also comment on declaration of `_suspend_requested`. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From tschatzl at openjdk.java.net Tue Apr 6 09:44:28 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 6 Apr 2021 09:44:28 GMT Subject: RFR: 8214455: Relocate CDS archived regions to the top of the G1 heap In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 21:48:43 GMT, Ioi Lam wrote: > When the runtime heap and dump time heap have different sizes, it's possible that the archived heap regions are mapped to the middle of the runtime heap. Because the archived heap regions are pinned, this could reduce the size of the largest "humongous" array allocation. In the worst case, the maximum allocatable array length may be half of the optimal value. > > The fix is to relocate the archived regions to the top of the G1 heap (currently archived regions are supported only by G1 on 64-bit JVM). > > Note that usually the top of the G1 heap is placed just below the 32GB boundary. As a result, the archived heap regions are at the same location between run time and dump time, so no relocation is necessary. > > In mach5 testing, we occasionally run into this problem (see https://bugs.openjdk.java.net/browse/JDK-8239089), probably because we fail to reserve the heap below 32GB due to address space layout randomization (ASLR). Lgtm. src/hotspot/share/memory/filemap.cpp line 1846: > 1844: _heap_pointers_need_patching = true; > 1845: } else if (header()->heap_end() != CompressedOops::end()) { > 1846: log_info(cds)("CDS heap data need to be relocated to the end of the runtime heap to reduce fragmentation"); s/need/needs test/hotspot/jtreg/runtime/cds/appcds/cacheObject/HeapFragmentationTest.java line 30: > 28: * @bug 8214455 > 29: * @requires vm.cds.archived.java.heap > 30: * @requires (sun.arch.data.model == "64" & os.maxMemory > 4g) additional space before the & ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3349 From rehn at openjdk.java.net Tue Apr 6 09:55:33 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 09:55:33 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 13:43:09 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/objectMonitor.cpp line 415: > >> 413: current->set_thread_state_fence(_thread_blocked_trans); >> 414: if (SafepointMechanism::should_process(current) && >> 415: current->suspend_request_pending()) { > > Shouldn't `suspend_request_pending()` be replaced with `is_suspended()`? See also comment on declaration of `_suspend_requested`. > And isn't checking `SafepointMechanism::should_process(current)` redundant? We don't want to always to take a lock (handshake state lock), if the poll is disarmed there cannot be any suspend request. We only need to unlock the OM for suspends that happened before we grabbed the OM lock in EnterI(). When we leave EnterI we are still blocked, this means a thread might be processing the suspend handshake, which was emitted before we did EnterI(). To synchronize the suspend check with such a thread we need to grab the HandshakeState lock, e.g. we cannot racy check the suspended flag. I choosed to check for an async suspension handshake that needs to be processed. (We can have such without being suspended). We could ignored that async handshake by just checking is_suspended, it would be processed in the else statement instead with "SafepointMechanism::process_if_requested(current);" instead. But we avoid releasing the OM lock in cases where we already have been resumed. So I can change to is_suspended inside the the method, but we still must do it under the HandshakeState lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 09:55:34 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 09:55:34 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> On Tue, 6 Apr 2021 09:48:50 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 415: >> >>> 413: current->set_thread_state_fence(_thread_blocked_trans); >>> 414: if (SafepointMechanism::should_process(current) && >>> 415: current->suspend_request_pending()) { >> >> Shouldn't `suspend_request_pending()` be replaced with `is_suspended()`? See also comment on declaration of `_suspend_requested`. >> And isn't checking `SafepointMechanism::should_process(current)` redundant? > > We don't want to always to take a lock (handshake state lock), if the poll is disarmed there cannot be any suspend request. > We only need to unlock the OM for suspends that happened before we grabbed the OM lock in EnterI(). > > When we leave EnterI we are still blocked, this means a thread might be processing the suspend handshake, which was emitted before we did EnterI(). > To synchronize the suspend check with such a thread we need to grab the HandshakeState lock, e.g. we cannot racy check the suspended flag. > > I choosed to check for an async suspension handshake that needs to be processed. (We can have such without being suspended). We could ignored that async handshake by just checking is_suspended, it would be processed in the else statement instead with "SafepointMechanism::process_if_requested(current);" instead. > > But we avoid releasing the OM lock in cases where we already have been resumed. > > So I can change to is_suspended inside the the method, but we still must do it under the HandshakeState lock. To clarify, is_suspended() can only be checked when the JavaThread is _unsafe_, *after* you have transitioned from the safe state. In this case we are checking if we are suspended before we have completed the transition because we need to know if we should drop the OM lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From sgehwolf at openjdk.java.net Tue Apr 6 10:09:16 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 6 Apr 2021 10:09:16 GMT Subject: RFR: 8264482: container info misleads on non-container environment [v2] In-Reply-To: References: <3xBZarV2-nFsRCB-iCLzNSE4H316QbfeZ61MHywMV9E=.215d64c5-1ad2-41df-926d-10941b734b3b@github.com> Message-ID: On Tue, 6 Apr 2021 03:26:52 GMT, Yasumasa Suenaga wrote: >>> If there is an issue with reporting this stuff when not actually in a container then the fault lies in is_containerized() IMHO. >> >> To resolve this problem, I think [JDK-8261242](https://bugs.openjdk.java.net/browse/JDK-8261242) is filed. But the discussion does not seem to active... it might take a lot of time to fix because there might not be clear solution to detect the process runs on the container. >> >> As I said in before, I want to remove "container" from log output because it makes to mislead. Especially next JDK release is LTS, so the code will use a long time. >> As an option, we can move logging code into `CgroupSubsystem`, but it might not be better... > >> If you are actually running under a cgroup and have resource limits >> applied then aren't you effectively running in a "container"? > > No, we can see container logs even if the process is not limited by cgroups. I (and maybe JDK-8261242) want to say it is a problem. > > HotSpot detects whether it is run on container in following code. It checks whether specified directories exist. > > https://github.com/openjdk/jdk/blob/54b4070da76e79597a57412a39b85660dc49ce7c/src/hotspot/os/linux/cgroupSubsystem_linux.cpp#L44-L48 > > According to [cgoups manpage](https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES), `/proc/cgroups` seems to generated by kernel, so we cannot use them to detect. > I think we should fix like systemd, and JDK-8261242 has been discussed on to do so. @YaSuenag Unfortunately that's the status quo, yes. On a plain linux system without cgroup limits for the java process, but with the cgroup subsystem mounted, it'll report some cgroup (container) metrics (same as the host values, though). What I'm unsure about is whether or not this is a problem worth fixing. The main idea is abstraction from cgroups in the container code. It does say `container (cgroup) information` in the heading. ------------- PR: https://git.openjdk.java.net/jdk/pull/3280 From rehn at openjdk.java.net Tue Apr 6 10:11:25 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 10:11:25 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 13:54:58 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 364: > >> 362: for (;;) { >> 363: simple_enter(jt); >> 364: if (!SafepointMechanism::should_process(jt)) { > > It seems to be likely that the condition is false in the first loop iteration and the thread has to do another iteration even if not suspended. Wouldn't it be ok to break from the loop if `!jt->is_suspended()`? > I'm asking because in ObjectMonitor::enter() L414 there is similar code and the condition there is `SafepointMechanism::should_process(current) && current->suspend_request_pending()` I didn't add that optimization here because I don't think it is needed, but I can add it. > src/hotspot/share/runtime/handshake.cpp line 486: > >> 484: // Asynchronous may block so they may not execute ~PreserveExceptionMark before safepointing >> 485: // in outer loop. >> 486: op->do_handshake(_handshakee); > > Maybe add PauseNoSafepointVerifier to document that the current thread can transition to a safe state? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 10:16:26 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 10:16:26 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 14:42:48 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/mutex.cpp line 244: > >> 242: wait_status = _lock.wait(timeout); >> 243: in_flight_mutex = this; // save for ~ThreadBlockInVM >> 244: > > Empty line can be removed. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 10:21:26 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 10:21:26 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 14:55:35 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/mutexLocker.hpp line 260: > >> 258: >> 259: bool wait(int64_t timeout = 0, >> 260: bool as_suspend_equivalent = !Mutex::_as_suspend_equivalent_flag) { > > The declaration of Mutex::_as_suspend_equivalent_flag should be removed. You might want to grep for 'equivalent' to find more that can be removed. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 10:54:27 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 10:54:27 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:22:34 GMT, David Holmes wrote: >> src/hotspot/share/runtime/os.cpp line 874: >> >>> 872: >>> 873: void os::start_thread(Thread* thread) { >>> 874: if (thread->is_Java_thread()) { >> >> Then and else blocks seem to do the very same things. > > Agreed - no need to distinguish between thread types here. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From jiefu at openjdk.java.net Tue Apr 6 10:55:26 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 6 Apr 2021 10:55:26 GMT Subject: RFR: 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to swapping not working [v2] In-Reply-To: References: <2QcFEnqjBIO1DIk7JmObayDiCVH9cvmyHOIZVrpznDY=.f3abf768-3a06-4525-9c36-3b2ba39a2e2a@github.com> Message-ID: <5LoWXCHJVaim9Bqd6T5LprMyvulzJjjzYpc3QshEE6s=.e410e27d-af9d-45dc-8d44-db49183effe0@github.com> On Tue, 6 Apr 2021 09:40:39 GMT, Severin Gehwolf wrote: > if (memAndSwapLimit <= memLimit) Hi @jerboaa , Unfortunately, this check fails to work on a host machine which doesn't support swapping (e.g., total size of Swap is 0 byte). You can still specify --memory and --memory-swap as you like on a host machine without swapping space. And Metrics.systemMetrics().getMemoryLimit()/getMemoryAndSwapLimit() do return the values as you specified. But the swapping will never happen since there is no swapping space on the host machine. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3286 From rehn at openjdk.java.net Tue Apr 6 11:12:34 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 11:12:34 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <8oSXNMTncb-dM6m7GCF2nmSD8uoRzYktoMXcW9PxOZE=.a6cc5682-c5f2-4584-ba2c-6a69f2f107fb@github.com> On Tue, 30 Mar 2021 19:49:45 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/safepointMechanism.cpp line 101: > >> 99: !thread->handshake_state()->process_by_self()) { >> 100: need_rechecking = true; >> 101: } > > What about this version > if (thread->handshake_state()->should_process()) { > need_rechecking = !thread->handshake_state()->process_by_self(); > } > or even > need_rechecking = > thread->handshake_state()->should_process() && !thread->handshake_state()->process_by_self(); > With the latter you could eliminate L82 > need_rechecking = false; > Also I'd find it more natural if `process_by_self()` could return true if rechecking is needed. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 11:12:35 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 11:12:35 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 20:27:46 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/sweeper.cpp line 276: > >> 274: >> 275: ThreadBlockInVM tbivm(thread); >> 276: thread->java_suspend_self(); > > In the baseline version of NMethodSweeper::handle_safepoint_request() there is a call `thread->java_suspend_self()`. This call will immediately return, won't it? Do you know what the purpose of this call was? The destructor of ThreadBlockInVM will block the current thread for the safepoint. So `java_suspend_self()` seems redundant. I don't know. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 11:12:32 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 11:12:32 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:59:27 GMT, David Holmes wrote: > Hi Robbin, > > This is a great piece of work with a lot of code simplifications. Unfortunately some new complexities that need to be hidden by appropriate abstractions. Lots of comments, queries and suggestions below. > > Thanks, > David Thanks David! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rrich at openjdk.java.net Tue Apr 6 11:31:38 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Apr 2021 11:31:38 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> References: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> Message-ID: On Tue, 6 Apr 2021 09:52:06 GMT, Robbin Ehn wrote: >> We don't want to always to take a lock (handshake state lock), if the poll is disarmed there cannot be any suspend request. >> We only need to unlock the OM for suspends that happened before we grabbed the OM lock in EnterI(). >> >> When we leave EnterI we are still blocked, this means a thread might be processing the suspend handshake, which was emitted before we did EnterI(). >> To synchronize the suspend check with such a thread we need to grab the HandshakeState lock, e.g. we cannot racy check the suspended flag. >> >> I choosed to check for an async suspension handshake that needs to be processed. (We can have such without being suspended). We could ignored that async handshake by just checking is_suspended, it would be processed in the else statement instead with "SafepointMechanism::process_if_requested(current);" instead. >> >> But we avoid releasing the OM lock in cases where we already have been resumed. >> >> So I can change to is_suspended inside the the method, but we still must do it under the HandshakeState lock. > > To clarify, is_suspended() can only be checked when the JavaThread is _unsafe_, *after* you have transitioned from the safe state. > In this case we are checking if we are suspended before we have completed the transition because we need to know if we should drop the OM lock. > > > We don't want to always to take a lock (handshake state lock), if the poll is disarmed there cannot be any suspend request. > We only need to unlock the OM for suspends that happened before we grabbed the OM lock in EnterI(). > > When we leave EnterI we are still blocked, this means a thread might be processing the suspend handshake, which was emitted before we did EnterI(). > To synchronize the suspend check with such a thread we need to grab the HandshakeState lock, e.g. we cannot racy check the suspended flag. I don't think that checking the suspended flag without holding the handshake state lock would be too racy. Holding the OM is sufficient synchronization for checking the suspended flag here. If the suspender thread S did the suspend request while holding the OM then the current thread T will see that it was suspended when it has entered the OM. If S did the suspend without holding OM, only then the check would be racy but that would be ok. > I choosed to check for an async suspension handshake that needs to be processed. (We can have such without being suspended). We could ignored that async handshake by just checking is_suspended, it would be processed in the else statement instead with "SafepointMechanism::process_if_requested(current);" instead. > > But we avoid releasing the OM lock in cases where we already have been resumed. > > So I can change to is_suspended inside the the method, but we still must do it under the HandshakeState lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rrich at openjdk.java.net Tue Apr 6 11:59:29 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Apr 2021 11:59:29 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> Message-ID: On Tue, 6 Apr 2021 11:28:26 GMT, Richard Reingruber wrote: >> To clarify, is_suspended() can only be checked when the JavaThread is _unsafe_, *after* you have transitioned from the safe state. >> In this case we are checking if we are suspended before we have completed the transition because we need to know if we should drop the OM lock. > >> >> >> We don't want to always to take a lock (handshake state lock), if the poll is disarmed there cannot be any suspend request. >> We only need to unlock the OM for suspends that happened before we grabbed the OM lock in EnterI(). >> >> When we leave EnterI we are still blocked, this means a thread might be processing the suspend handshake, which was emitted before we did EnterI(). >> To synchronize the suspend check with such a thread we need to grab the HandshakeState lock, e.g. we cannot racy check the suspended flag. > > I don't think that checking the suspended flag without holding the handshake > state lock would be too racy. Holding the OM is sufficient synchronization for > checking the suspended flag here. > > If the suspender thread S did the suspend request while holding the OM then the > current thread T will see that it was suspended when it has entered the OM. > If S did the suspend without holding OM, only then the check would be racy but that would be ok. > >> I choosed to check for an async suspension handshake that needs to be processed. (We can have such without being suspended). We could ignored that async handshake by just checking is_suspended, it would be processed in the else statement instead with "SafepointMechanism::process_if_requested(current);" instead. >> >> But we avoid releasing the OM lock in cases where we already have been resumed. >> >> So I can change to is_suspended inside the the method, but we still must do it under the HandshakeState lock. > > > To clarify, is_suspended() can only be checked when the JavaThread is _unsafe_, _after_ you have transitioned from the safe state. For a minute I misunderstood this and thought you meant this as a general rule for calling `is_suspended()` while there are examples where it is called without any synchronization (e.g. in `JvmtiEnv::GetThreadState()`) which can be ok. > In this case we are checking if we are suspended before we have completed the transition because we need to know if we should drop the OM lock. I think it is sufficient to hold the OM when calling `is_suspended` to decide if OM has to be dropped. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rrich at openjdk.java.net Tue Apr 6 11:59:29 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Apr 2021 11:59:29 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <6kAUUsRWTc5_nRULmaJN3HLT47eRR0az61k5BDdoTrE=.9cacc103-bac5-44f4-b61c-749f3f587f6f@github.com> On Tue, 6 Apr 2021 10:07:56 GMT, Robbin Ehn wrote: > > > Sorry, the PauseNoSafepointVerifier needs the nsv in it's constructor and it's not in this scope. > I can't easily add that. Sorry, I overlooked that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 11:59:29 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 11:59:29 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> Message-ID: <1ezluoPSA1_4PpSyTQKh2dNkBMGMTtlEg3BEzFxCLEo=.36b8a600-8148-4bfb-b8d7-1393b8cf29d7@github.com> On Tue, 6 Apr 2021 11:49:42 GMT, Richard Reingruber wrote: >>> >>> >>> We don't want to always to take a lock (handshake state lock), if the poll is disarmed there cannot be any suspend request. >>> We only need to unlock the OM for suspends that happened before we grabbed the OM lock in EnterI(). >>> >>> When we leave EnterI we are still blocked, this means a thread might be processing the suspend handshake, which was emitted before we did EnterI(). >>> To synchronize the suspend check with such a thread we need to grab the HandshakeState lock, e.g. we cannot racy check the suspended flag. >> >> I don't think that checking the suspended flag without holding the handshake >> state lock would be too racy. Holding the OM is sufficient synchronization for >> checking the suspended flag here. >> >> If the suspender thread S did the suspend request while holding the OM then the >> current thread T will see that it was suspended when it has entered the OM. >> If S did the suspend without holding OM, only then the check would be racy but that would be ok. >> >>> I choosed to check for an async suspension handshake that needs to be processed. (We can have such without being suspended). We could ignored that async handshake by just checking is_suspended, it would be processed in the else statement instead with "SafepointMechanism::process_if_requested(current);" instead. >>> >>> But we avoid releasing the OM lock in cases where we already have been resumed. >>> >>> So I can change to is_suspended inside the the method, but we still must do it under the HandshakeState lock. > >> >> >> To clarify, is_suspended() can only be checked when the JavaThread is _unsafe_, _after_ you have transitioned from the safe state. > > For a minute I misunderstood this and thought you meant this as a general rule > for calling `is_suspended()` while there are examples where it is called without > any synchronization (e.g. in `JvmtiEnv::GetThreadState()`) which can be ok. > >> In this case we are checking if we are suspended before we have completed the transition because we need to know if we should drop the OM lock. > > I think it is sufficient to hold the OM when calling `is_suspended` to decide if OM has to be dropped. I do not follow, the OM is unrelated. The suspender do not hold the OM. What happens is: - Thread A wait on OM X in blocked. - Thread Z suspends Thread A, thread Z have no relation to OM X. - Thread B unlocks OM X, thread B have no relation to the suspend request. - Thread A locks OM X while blocked. - Thread A was not allowed to lock OM X due to it is actually suspended. - Thread A unlocks OM X and waits until resumed. So while A and B fight over OM X, A is trying to figure out if Z suspended him while grabbing the lock. The suspend flag and 'async handshake' flag are protected by the HandshakeState lock. (this is not lockless protocol) The stores in SuspendThreadHandshake are not ordered, so they may happen in any order. To read the stores there you must hold the HandshakeState lock. Therefore if we want the exact answer to am A suspended we must read the flag under the lock. Makes sense? ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From ysuenaga at openjdk.java.net Tue Apr 6 12:09:28 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 6 Apr 2021 12:09:28 GMT Subject: RFR: 8264482: container info misleads on non-container environment [v2] In-Reply-To: References: <3xBZarV2-nFsRCB-iCLzNSE4H316QbfeZ61MHywMV9E=.215d64c5-1ad2-41df-926d-10941b734b3b@github.com> Message-ID: On Tue, 6 Apr 2021 10:06:18 GMT, Severin Gehwolf wrote: > What I'm unsure about is whether or not this is a problem worth fixing. I think fundamental solutions will be implemented in JDK-8261242, but It seems to be a difficult task. > The main idea is abstraction from cgroups in the container code. It does say `container (cgroup) information` in the heading. I know that, but "container_type" label is in hs_err / VM.info log. In addition, UL reports some metrics as "container" in spite of cgroups. If it takes a long time to fix JDK-8261242, I want to fix log messages for cgroups for next LTS release at least. "container" messages may make the customer do extra work to collect / analyzer their system. ------------- PR: https://git.openjdk.java.net/jdk/pull/3280 From coleenp at openjdk.java.net Tue Apr 6 12:21:21 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 6 Apr 2021 12:21:21 GMT Subject: RFR: 8264742: member variable _monitor of MonitorLocker is redundant In-Reply-To: References: Message-ID: <2QEsOPbspwmgk3-FQEZupvhNNvnSy9IbZi-qeS4adt0=.7098c68e-7795-481a-8445-f1a177f351b3@github.com> On Tue, 6 Apr 2021 04:05:21 GMT, Xin Liu wrote: > MonitorLocker is a subclass of MutexLocker. The member variable _monitor > has the same value of _mutex in its base class. This is ok. I was worried about the cast defeating type safety but as long as as_monitor is in MonitorLocker, that's fine. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3350 From rrich at openjdk.java.net Tue Apr 6 12:26:35 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Apr 2021 12:26:35 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: <1ezluoPSA1_4PpSyTQKh2dNkBMGMTtlEg3BEzFxCLEo=.36b8a600-8148-4bfb-b8d7-1393b8cf29d7@github.com> References: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> <1ezluoPSA1_4PpSyTQKh2dNkBMGMTtlEg3BEzFxCLEo=.36b8a600-8148-4bfb-b8d7-1393b8cf29d7@github.com> Message-ID: On Tue, 6 Apr 2021 11:56:36 GMT, Robbin Ehn wrote: > > > I do not follow, the OM is unrelated. > The suspender do not hold the OM. > > What happens is: > > * Thread A wait on OM X in blocked. > > * Thread Z suspends Thread A, thread Z have no relation to OM X. > > * Thread B unlocks OM X, thread B have no relation to the suspend request. > > * Thread A locks OM X while blocked. > > * Thread A was not allowed to lock OM X due to it is actually suspended. > > * Thread A unlocks OM X and waits until resumed. > > > So while A and B fight over OM X, A is trying to figure out if Z suspended him while grabbing the lock. If understand the example correctly then the suspend operation and the operations on OM X are unordered with respect to each other. If so, then we can put them into an order where the suspend happens after "Thread A locks OM X while blocked.". We are free to do this; there's no synchronization that would prevent it. Also when the suspend request happened while A was blocked then after `current->set_thread_state_fence(_thread_blocked_trans);` the check of `is_suspended()` will return true even if the handshake state lock is not acquired for the check. And if Z tried to suspend A after the state change then Z will block because A is not safe anymore. Sorry for insisting. I really hope I'm not wrong ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 12:26:35 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 12:26:35 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 10:22:28 GMT, Richard Reingruber wrote: >> My comment was about JVMTI_ERROR_THREAD_NOT_ALIVE > > Sure. I agree with your comment. I think we should add JVMTI_ERROR_THREAD_SUSPENDED as @reinrich says, it is possible for someone to sneak in a second suspend request before us. @dcubed-ojdk it seem like we could be posting JvmtiExport::post_monitor_contended_enter() from the ensure_join() which locks the threadObj. So it might be best to treat this the same way as the others? ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From sgehwolf at openjdk.java.net Tue Apr 6 12:31:35 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 6 Apr 2021 12:31:35 GMT Subject: RFR: 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to swapping not working [v2] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 04:03:45 GMT, Jie Fu wrote: >> Hi all, >> >> jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails on some of our testing platforms. >> This is because testMemoryFailCount [1] fails due to OOM killed. >> This test fails to avoid OOM killed [2] if memory.failcnt is always 0. >> >> The fix will print "Not OOM killed" if OOM killed doesn't happen. >> And also fix another bug if the test get returned here [3]. >> >> Testing: >> - jdk/internal/platform/docker/ hotspot/jtreg/containers on Linux/x64 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java#L80 >> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L87 >> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L96 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Check swapping before testing Changes requested by sgehwolf (Reviewer). test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java line 106: > 104: Common.logNewTestCase("testMemoryFailCount" + value); > 105: > 106: // Check whether swapping really works for this test Please explain what "swapping not working" actually means in this comment. One version of it is already handled via JDK-8250984 so this is sort-of ambiguous. Suggestion: "On some systems there is no swap space enabled. On those systems running `java -version`??? with a memory limit fails due to swap space size being 0". Or something like that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3286 From rehn at openjdk.java.net Tue Apr 6 12:48:35 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 12:48:35 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> <1ezluoPSA1_4PpSyTQKh2dNkBMGMTtlEg3BEzFxCLEo=.36b8a600-8148-4bfb-b8d7-1393b8cf29d7@github.com> Message-ID: On Tue, 6 Apr 2021 12:23:06 GMT, Richard Reingruber wrote: >> I do not follow, the OM is unrelated. >> The suspender do not hold the OM. >> >> What happens is: >> - Thread A wait on OM X in blocked. >> - Thread Z suspends Thread A, thread Z have no relation to OM X. >> - Thread B unlocks OM X, thread B have no relation to the suspend request. >> - Thread A locks OM X while blocked. >> - Thread A was not allowed to lock OM X due to it is actually suspended. >> - Thread A unlocks OM X and waits until resumed. >> >> So while A and B fight over OM X, A is trying to figure out if Z suspended him while grabbing the lock. >> >> The suspend flag and 'async handshake' flag are protected by the HandshakeState lock. (this is not lockless protocol) >> The stores in SuspendThreadHandshake are not ordered, so they may happen in any order. >> To read the stores there you must hold the HandshakeState lock. >> Therefore if we want the exact answer to am A suspended we must read the flag under the lock. >> >> Makes sense? > >> >> >> I do not follow, the OM is unrelated. >> The suspender do not hold the OM. >> >> What happens is: >> >> * Thread A wait on OM X in blocked. >> >> * Thread Z suspends Thread A, thread Z have no relation to OM X. >> >> * Thread B unlocks OM X, thread B have no relation to the suspend request. >> >> * Thread A locks OM X while blocked. >> >> * Thread A was not allowed to lock OM X due to it is actually suspended. >> >> * Thread A unlocks OM X and waits until resumed. >> >> >> So while A and B fight over OM X, A is trying to figure out if Z suspended him while grabbing the lock. > > If understand the example correctly then the suspend operation and the > operations on OM X are unordered with respect to each other. If so, then we can > put them into an order where the suspend happens after "Thread A locks OM X while > blocked.". We are free to do this; there's no synchronization that would prevent it. > > Also when the suspend request happened while A was blocked then after > `current->set_thread_state_fence(_thread_blocked_trans);` the check of > `is_suspended()` will return true even if the handshake state lock is not > acquired for the check. And if Z tried to suspend A after the state change then > Z will block because A is not safe anymore. > > Sorry for insisting. I really hope I'm not wrong ;) The only reason _suspended is volatile is to be able to make the the fast check in resume(). So disregard that early check and that it is volatile, the users of the flag uses HandshakeState lock for synchronizing reads and stores to that flag. E.g set_suspend(true); set_async_suspend_handshake(true); log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended, arming ThreadSuspension", p2i(_handshakee)); ThreadSuspensionHandshake* ts = new ThreadSuspensionHandshake(); Handshake::execute(ts, _handshakee); Before we have enqueued the async handshake there is no trap and but the flag set_suspend(true). This means we will miss the async handshake and continue to executed with suspended flag. Both flags and async handshake are set atomically by serializing over the HnadshakeState lock. In this case we want to both know if we are suspended if so process the suspension. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 12:57:32 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 12:57:32 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> <1ezluoPSA1_4PpSyTQKh2dNkBMGMTtlEg3BEzFxCLEo=.36b8a600-8148-4bfb-b8d7-1393b8cf29d7@github.com> Message-ID: On Tue, 6 Apr 2021 12:44:01 GMT, Robbin Ehn wrote: >>> >>> >>> I do not follow, the OM is unrelated. >>> The suspender do not hold the OM. >>> >>> What happens is: >>> >>> * Thread A wait on OM X in blocked. >>> >>> * Thread Z suspends Thread A, thread Z have no relation to OM X. >>> >>> * Thread B unlocks OM X, thread B have no relation to the suspend request. >>> >>> * Thread A locks OM X while blocked. >>> >>> * Thread A was not allowed to lock OM X due to it is actually suspended. >>> >>> * Thread A unlocks OM X and waits until resumed. >>> >>> >>> So while A and B fight over OM X, A is trying to figure out if Z suspended him while grabbing the lock. >> >> If understand the example correctly then the suspend operation and the >> operations on OM X are unordered with respect to each other. If so, then we can >> put them into an order where the suspend happens after "Thread A locks OM X while >> blocked.". We are free to do this; there's no synchronization that would prevent it. >> >> Also when the suspend request happened while A was blocked then after >> `current->set_thread_state_fence(_thread_blocked_trans);` the check of >> `is_suspended()` will return true even if the handshake state lock is not >> acquired for the check. And if Z tried to suspend A after the state change then >> Z will block because A is not safe anymore. >> >> Sorry for insisting. I really hope I'm not wrong ;) > > The only reason _suspended is volatile is to be able to make the the fast check in resume(). > So disregard that early check and that it is volatile, the users of the flag uses HandshakeState lock for synchronizing reads and stores to that flag. > > E.g > set_suspend(true); > set_async_suspend_handshake(true); > log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended, arming ThreadSuspension", p2i(_handshakee)); > ThreadSuspensionHandshake* ts = new ThreadSuspensionHandshake(); > Handshake::execute(ts, _handshakee); > > Before we have enqueued the async handshake there is no trap and but the flag set_suspend(true). > This means we will miss the async handshake and continue to executed with suspended flag. > > Both flags and async handshake are set atomically by serializing over the HnadshakeState lock. > > In this case we want to both know if we are suspended if so process the suspension. (technically this will be ordered by the poll is since polls are only disarmed by threads them selfs) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From vlivanov at openjdk.java.net Tue Apr 6 13:01:53 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 6 Apr 2021 13:01:53 GMT Subject: RFR: 8264731: Introduce InstanceKlass::method_at_itable_or_null() [v2] In-Reply-To: References: Message-ID: > Introduce `InstanceKlass::method_at_itable_or_null()` - a non-throwing variant of `InstanceKlass::method_at_itable()` that implements interface method selection. > > As a cleanup, rewrite `InstanceKlass::method_at_itable()` on top of `InstanceKlass::method_at_itable_or_null()`. > > Testing: > * [x] hs-tier1 - hs-tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Cleanups ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3344/files - new: https://git.openjdk.java.net/jdk/pull/3344/files/2755b483..91b977c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3344&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3344&range=00-01 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3344.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3344/head:pull/3344 PR: https://git.openjdk.java.net/jdk/pull/3344 From vlivanov at openjdk.java.net Tue Apr 6 13:01:57 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 6 Apr 2021 13:01:57 GMT Subject: RFR: 8264731: Introduce InstanceKlass::method_at_itable_or_null() [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 02:52:50 GMT, David Holmes wrote: > I assume more callers of the new API are in the pipeline? Yes, the plan is to use it in CHA (`dependencies.cpp/hpp`). I decided to integrate runtime-related code changes separately. > src/hotspot/share/oops/instanceKlass.cpp line 3154: > >> 3152: >> 3153: Method* InstanceKlass::method_at_itable(InstanceKlass* holder, int index, TRAPS) { >> 3154: bool itable_entry_found; // out parameter > > I was very confused about the logic in this code until I realized that itable_entry_found is actually an indicator as to whether or not the current class implements the interface represented by holder, and not an indicator of whether or not a method was found. It would be much clearer to me if this variable were renamed something like implements_interface. Agree. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3344 From vlivanov at openjdk.java.net Tue Apr 6 13:05:19 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 6 Apr 2021 13:05:19 GMT Subject: RFR: 8264731: Introduce InstanceKlass::method_at_itable_or_null() [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 02:01:29 GMT, Coleen Phillimore wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanups > > src/hotspot/share/oops/instanceKlass.cpp line 3179: > >> 3177: >> 3178: Method* InstanceKlass::method_at_itable_or_null(InstanceKlass* holder, int index, bool& itable_entry_found) { >> 3179: klassItable itable(this); > > I think you need a ResourceMark before this. Can you elaborate, please, why you think so? I don't see anything in `klassItable` which may allocate in the resource arena. ------------- PR: https://git.openjdk.java.net/jdk/pull/3344 From rehn at openjdk.java.net Tue Apr 6 13:10:31 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 13:10:31 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <3R504XyTsO1yytT_Mkt9EU1JFSP91nUdjtl0njFZFzw=.a0794436-09de-448a-b53e-8eb36c5a481f@github.com> On Wed, 31 Mar 2021 14:01:19 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/prims/jvmtiEnv.cpp line 946: >> >>> 944: // java_thread - pre-checked >>> 945: jvmtiError >>> 946: JvmtiEnv::SuspendThread(JavaThread* java_thread) { >> >> The comment above this still states: >> >> // Threads_lock NOT held, java_thread not protected by lock >> >> but the java_thread is protected by a TLH so we should document that so we know it is always safe to refer to java_thread below. > > These `Threads_lock NOT held ...` comments in JVM/TI are a left over > issue from the Thread-SMR project and I think I forgot to file a follow-up > bug to clean those up. > > I recommend handling that in a general cleanup issue for all of these > comments in JVM/TI (and possibly elsewhere). Please let me know if I > should go ahead and file that bug. Yes, please file that issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 6 13:10:34 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 13:10:34 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <1WF1UhbRqexQnJon-jE6hzSAQSesYP9CSh1LyRQwprs=.6a57db9f-8e38-4554-ad32-941a9d0b6b5e@github.com> On Wed, 31 Mar 2021 03:51:02 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/prims/jvmtiImpl.cpp line 767: > >> 765: // >> 766: >> 767: bool JvmtiSuspendControl::suspend(JavaThread *java_thread) { > > Future RFE: JvmtiSuspendControl is no longer needed Yes ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From jiefu at openjdk.java.net Tue Apr 6 13:11:54 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 6 Apr 2021 13:11:54 GMT Subject: RFR: 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to swapping not working [v3] In-Reply-To: References: Message-ID: > Hi all, > > jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails on some of our testing platforms. > This is because testMemoryFailCount [1] fails due to OOM killed. > This test fails to avoid OOM killed [2] if memory.failcnt is always 0. > > The fix will print "Not OOM killed" if OOM killed doesn't happen. > And also fix another bug if the test get returned here [3]. > > Testing: > - jdk/internal/platform/docker/ hotspot/jtreg/containers on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java#L80 > [2] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L87 > [3] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L96 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Update the comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3286/files - new: https://git.openjdk.java.net/jdk/pull/3286/files/3e1c446d..101b90d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3286&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3286&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3286.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3286/head:pull/3286 PR: https://git.openjdk.java.net/jdk/pull/3286 From jiefu at openjdk.java.net Tue Apr 6 13:11:57 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 6 Apr 2021 13:11:57 GMT Subject: RFR: 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to swapping not working [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 12:27:56 GMT, Severin Gehwolf wrote: > Please explain what "swapping not working" actually means in this comment. Updated. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3286 From coleenp at openjdk.java.net Tue Apr 6 13:21:26 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 6 Apr 2021 13:21:26 GMT Subject: RFR: 8264731: Introduce InstanceKlass::method_at_itable_or_null() [v2] In-Reply-To: References: Message-ID: <7zxs3_bIozKsJc3RnVu-PuwUFQGELSWHjIH1PXbNHEw=.fd2148bf-18d3-4943-a9a7-55ff52b2e469@github.com> On Tue, 6 Apr 2021 13:02:38 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 3179: >> >>> 3177: >>> 3178: Method* InstanceKlass::method_at_itable_or_null(InstanceKlass* holder, int index, bool& itable_entry_found) { >>> 3179: klassItable itable(this); >> >> I think you need a ResourceMark before this. > > Can you elaborate, please, why you think so? > I don't see anything in `klassItable` which may allocate in the resource arena. oh, never mind. Somebody fixed this a long time ago. ------------- PR: https://git.openjdk.java.net/jdk/pull/3344 From vlivanov at openjdk.java.net Tue Apr 6 13:41:48 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 6 Apr 2021 13:41:48 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v2] In-Reply-To: References: Message-ID: > Turn `resolved_method` parameter into raw `Method*`. > > Testing: > * [x] hs-tier1 - hs-tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Revert jvmciCompilerToVM.cpp change. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3346/files - new: https://git.openjdk.java.net/jdk/pull/3346/files/89e0b67d..a2bf4794 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3346&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3346&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3346/head:pull/3346 PR: https://git.openjdk.java.net/jdk/pull/3346 From vlivanov at openjdk.java.net Tue Apr 6 13:41:52 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 6 Apr 2021 13:41:52 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v2] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 19:09:21 GMT, Coleen Phillimore wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert jvmciCompilerToVM.cpp change. > > src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 731: > >> 729: C2V_VMENTRY_0(jint, getVtableIndexForInterfaceMethod, (JNIEnv* env, jobject, jobject jvmci_type, jobject jvmci_method)) >> 730: Klass* klass = JVMCIENV->asKlass(jvmci_type); >> 731: Method* method = JVMCIENV->asMethod(jvmci_method); > > The reason that resolved_method was a methodHandle is in case of redefinition, we need to know if code is referring to this version of the method so that it's not deallocated. It's enough for one of the callers to create a methodHandle but passing the methodHandle will guarantee it. I'm not sure why you needed to make this change. I refactored `getVtableIndexForInterfaceMethod` and kept the handle in place while dereferencing it when passing into `vtable_index_of_interface_method`. Does it look better now? ------------- PR: https://git.openjdk.java.net/jdk/pull/3346 From sgehwolf at openjdk.java.net Tue Apr 6 13:48:24 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 6 Apr 2021 13:48:24 GMT Subject: RFR: 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to swapping not working [v3] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 13:11:54 GMT, Jie Fu wrote: >> Hi all, >> >> jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails on some of our testing platforms. >> This is because testMemoryFailCount [1] fails due to OOM killed. >> This test fails to avoid OOM killed [2] if memory.failcnt is always 0. >> >> The fix will print "Not OOM killed" if OOM killed doesn't happen. >> And also fix another bug if the test get returned here [3]. >> >> Testing: >> - jdk/internal/platform/docker/ hotspot/jtreg/containers on Linux/x64 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java#L80 >> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L87 >> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L96 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Update the comment LGTM. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3286 From coleenp at openjdk.java.net Tue Apr 6 14:23:19 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 6 Apr 2021 14:23:19 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 13:41:48 GMT, Vladimir Ivanov wrote: >> Turn `resolved_method` parameter into raw `Method*`. >> >> Testing: >> * [x] hs-tier1 - hs-tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Revert jvmciCompilerToVM.cpp change. Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3346 From coleenp at openjdk.java.net Tue Apr 6 14:23:20 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 6 Apr 2021 14:23:20 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 13:37:53 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 731: >> >>> 729: C2V_VMENTRY_0(jint, getVtableIndexForInterfaceMethod, (JNIEnv* env, jobject, jobject jvmci_type, jobject jvmci_method)) >>> 730: Klass* klass = JVMCIENV->asKlass(jvmci_type); >>> 731: Method* method = JVMCIENV->asMethod(jvmci_method); >> >> The reason that resolved_method was a methodHandle is in case of redefinition, we need to know if code is referring to this version of the method so that it's not deallocated. It's enough for one of the callers to create a methodHandle but passing the methodHandle will guarantee it. I'm not sure why you needed to make this change. > > I refactored `getVtableIndexForInterfaceMethod` and kept the handle in place while dereferencing it when passing into `vtable_index_of_interface_method`. Does it look better now? Ok, this is fine. Be careful if you have new callers for this function. ------------- PR: https://git.openjdk.java.net/jdk/pull/3346 From coleenp at openjdk.java.net Tue Apr 6 14:34:27 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 6 Apr 2021 14:34:27 GMT Subject: RFR: 8264682: MemProfiling does not own Heap_lock when using G1 In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 02:04:57 GMT, David Holmes wrote: >> Trivial fix for JDK-8264682. >> >> `Universe::heap()->used()` calls G1Allocator::used_in_alloc_regions() when G1 enabled, it checks whether Heap_lock was owned on this thread's behalf. > > Sorry but I have to agree with Kim that this is the wrong fix for this problem. > > And the test needs adjusting. > > Thanks, > David Unless we can imagine a reason why this code is needed, I think the old memprofiler should be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3340 From gziemski at openjdk.java.net Tue Apr 6 15:02:20 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 6 Apr 2021 15:02:20 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v3] In-Reply-To: <07xszQhnfsbFlftK7fHgoFGVRhG9m_IPPUOg1-j120M=.7ae018d5-227e-448a-ad13-913c1ecd2ff1@github.com> References: <07xszQhnfsbFlftK7fHgoFGVRhG9m_IPPUOg1-j120M=.7ae018d5-227e-448a-ad13-913c1ecd2ff1@github.com> Message-ID: On Tue, 6 Apr 2021 01:22:48 GMT, Yasumasa Suenaga wrote: >> `jdk.CPUInformation` event on AArch64 has valid CPU description in [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491), however it does not work on UEFI booted machine. >> >> [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491) refers device tree to get board name, however it does not exist on UEFI. We need to refer DMI. >> However we need to have root privilege, so we refer /sys/devices/virtual/dmi/id to avoid it. >> >> We can get board name from /sys/devices/virtual/dmi/id/board_name, but some machine set empty string to it. So we will refer /sys/devices/virtual/dmi/id/product_name as a fallback. >> >> For example, we can get following CPU description on AWS A1 instance after this change: >> >> jdk.CPUInformation { >> startTime = 05:28:24.506 >> cpu = "AArch64" >> description = "AArch64 a1.2xlarge 0x41:0x0:0xd08:3, simd, crc, aes, sha1, sha256" >> sockets = 8 >> cores = 8 >> hwThreads = 8 >> } > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Use functions in os class Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From rrich at openjdk.java.net Tue Apr 6 15:49:33 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Apr 2021 15:49:33 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> <1ezluoPSA1_4PpSyTQKh2dNkBMGMTtlEg3BEzFxCLEo=.36b8a600-8148-4bfb-b8d7-1393b8cf29d7@github.com> Message-ID: On Tue, 6 Apr 2021 12:54:40 GMT, Robbin Ehn wrote: >> The only reason _suspended is volatile is to be able to make the the fast check in resume(). >> So disregard that early check and that it is volatile, the users of the flag uses HandshakeState lock for synchronizing reads and stores to that flag. >> >> E.g >> set_suspend(true); >> set_async_suspend_handshake(true); >> log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended, arming ThreadSuspension", p2i(_handshakee)); >> ThreadSuspensionHandshake* ts = new ThreadSuspensionHandshake(); >> Handshake::execute(ts, _handshakee); >> >> Before we have enqueued the async handshake there is no trap and but the flag set_suspend(true). >> This means we will miss the async handshake and continue to executed with suspended flag. >> >> Both flags and async handshake are set atomically by serializing over the HnadshakeState lock. >> >> In this case we want to both know if we are suspended if so process the suspension. > > (technically this will be ordered by the poll is since polls are only disarmed by threads them selfs) > (meaning if you really promise to call should_process() after you have seen "set_suspend(true);" you will see the async handshake since then we do take the HandshakeState lock.) > Also when the suspend request happened while A was blocked then after > current->set_thread_state_fence(_thread_blocked_trans); the check of > is_suspended() will return true even if the handshake state lock is not > acquired for the check That statement of mine is wrong. (Hopefully) correct is that after the complete state change from _thread_blocked to _thread_in_vm which includes being blocked for a safepoint/handshake the current thread would be able to check is_suspended() without holding the handshake state lock. It does not make a lot of sense then because in an unsafe state JavaThread::current()->is_suspended() will always return false. > Thread A wait on OM X in blocked. > Thread Z suspends Thread A, thread Z have no relation to OM X. > Thread B unlocks OM X, thread B have no relation to the suspend request. > Thread A locks OM X while blocked. > Thread A was not allowed to lock OM X due to it is actually suspended. > Thread A unlocks OM X and waits until resumed. I understand that example now too: OM and suspend operations are unrelated. So I thought it would be ok for A to enter OM X, but it is not. A thread must not leave a safe state if it was suspended in that state (with a handshake). If it did, e.g., its stack could become not walkable. And it must not enter the monitor either. Sorry for the confusion. The check is good. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rrich at openjdk.java.net Tue Apr 6 16:28:52 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Apr 2021 16:28:52 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 10:05:08 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 364: >> >>> 362: for (;;) { >>> 363: simple_enter(jt); >>> 364: if (!SafepointMechanism::should_process(jt)) { >> >> It seems to be likely that the condition is false in the first loop iteration and the thread has to do another iteration even if not suspended. Wouldn't it be ok to break from the loop if `!jt->is_suspended()`? >> I'm asking because in ObjectMonitor::enter() L414 there is similar code and the condition there is `SafepointMechanism::should_process(current) && current->suspend_request_pending()` > > I didn't add that optimization here because I don't think it is needed, but I can add it. Your version is good. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From iklam at openjdk.java.net Tue Apr 6 17:04:19 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Apr 2021 17:04:19 GMT Subject: RFR: 8214455: Relocate CDS archived regions to the top of the G1 heap [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 09:35:01 GMT, Thomas Schatzl wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @tschatzl review -- fix typos and whitespace > > src/hotspot/share/memory/filemap.cpp line 1846: > >> 1844: _heap_pointers_need_patching = true; >> 1845: } else if (header()->heap_end() != CompressedOops::end()) { >> 1846: log_info(cds)("CDS heap data need to be relocated to the end of the runtime heap to reduce fragmentation"); > > s/need/needs Fixed. > test/hotspot/jtreg/runtime/cds/appcds/cacheObject/HeapFragmentationTest.java line 30: > >> 28: * @bug 8214455 >> 29: * @requires vm.cds.archived.java.heap >> 30: * @requires (sun.arch.data.model == "64" & os.maxMemory > 4g) > > additional space before the & Fixed. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3349 From iklam at openjdk.java.net Tue Apr 6 17:04:18 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Apr 2021 17:04:18 GMT Subject: RFR: 8214455: Relocate CDS archived regions to the top of the G1 heap [v2] In-Reply-To: References: Message-ID: > When the runtime heap and dump time heap have different sizes, it's possible that the archived heap regions are mapped to the middle of the runtime heap. Because the archived heap regions are pinned, this could reduce the size of the largest "humongous" array allocation. In the worst case, the maximum allocatable array length may be half of the optimal value. > > The fix is to relocate the archived regions to the top of the G1 heap (currently archived regions are supported only by G1 on 64-bit JVM). > > Note that usually the top of the G1 heap is placed just below the 32GB boundary. As a result, the archived heap regions are at the same location between run time and dump time, so no relocation is necessary. > > In mach5 testing, we occasionally run into this problem (see https://bugs.openjdk.java.net/browse/JDK-8239089), probably because we fail to reserve the heap below 32GB due to address space layout randomization (ASLR). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @tschatzl review -- fix typos and whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3349/files - new: https://git.openjdk.java.net/jdk/pull/3349/files/def7db7b..bedd676d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3349&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3349&range=00-01 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3349/head:pull/3349 PR: https://git.openjdk.java.net/jdk/pull/3349 From pchilanomate at openjdk.java.net Tue Apr 6 17:31:36 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 6 Apr 2021 17:31:36 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> <1ezluoPSA1_4PpSyTQKh2dNkBMGMTtlEg3BEzFxCLEo=.36b8a600-8148-4bfb-b8d7-1393b8cf29d7@github.com> Message-ID: On Tue, 6 Apr 2021 15:46:17 GMT, Richard Reingruber wrote: >> (technically this will be ordered by the poll is since polls are only disarmed by threads them selfs) >> (meaning if you really promise to call should_process() after you have seen "set_suspend(true);" you will see the async handshake since then we do take the HandshakeState lock.) > >> Also when the suspend request happened while A was blocked then after >> current->set_thread_state_fence(_thread_blocked_trans); the check of >> is_suspended() will return true even if the handshake state lock is not >> acquired for the check > > That statement of mine is wrong. (Hopefully) correct is that after the complete > state change from _thread_blocked to _thread_in_vm which includes being blocked > for a safepoint/handshake the current thread would be able to check > is_suspended() without holding the handshake state lock. It does not make a lot > of sense then because in an unsafe state JavaThread::current()->is_suspended() > will always return false. > >> Thread A wait on OM X in blocked. >> Thread Z suspends Thread A, thread Z have no relation to OM X. >> Thread B unlocks OM X, thread B have no relation to the suspend request. >> Thread A locks OM X while blocked. >> Thread A was not allowed to lock OM X due to it is actually suspended. >> Thread A unlocks OM X and waits until resumed. > > I understand that example now too: OM and suspend operations are unrelated. So I > thought it would be ok for A to enter OM X, but it is not. A thread must not > leave a safe state if it was suspended in that state (with a handshake). If it > did, e.g., its stack could become not walkable. And it must not enter the > monitor either. > > Sorry for the confusion. The check is good. But I still think we can just call is_suspended() here. If is_suspended() returns false, then Z hasn't finished suspending A yet (either async operation was still not added to the queue in case this is the first suspend for A, or do_handshake() hasn't yet finished for that SuspendThreadHandshake operation in case there was already an async operation in the queue). Since we have already acquired OM, then Z will not see that after being suspended A switched from not owning OM to owning it. It will always see that A owned OM. And A will still block for the suspension in the 'else' clause since poll is armed due to SuspendThreadHandshake operation(even if async operation was still not added to the queue at the time A called is_suspended()), but we wouldn't need to release OM. If is_suspended() returns true then at most we will have a false positive, since it could be that after the check somebody already resumed A, but that can also happen even with suspend_request_pending() right after releasing HandshakeState::_lock. Is that correct or am I missing something? ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From xliu at openjdk.java.net Tue Apr 6 17:46:30 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 6 Apr 2021 17:46:30 GMT Subject: RFR: 8264742: member variable _monitor of MonitorLocker is redundant In-Reply-To: <2QEsOPbspwmgk3-FQEZupvhNNvnSy9IbZi-qeS4adt0=.7098c68e-7795-481a-8445-f1a177f351b3@github.com> References: <2QEsOPbspwmgk3-FQEZupvhNNvnSy9IbZi-qeS4adt0=.7098c68e-7795-481a-8445-f1a177f351b3@github.com> Message-ID: On Tue, 6 Apr 2021 12:18:41 GMT, Coleen Phillimore wrote: > This is ok. I was worried about the cast defeating type safety but as long as as_monitor is in MonitorLocker, that's fine. hi, Coleen, Thank you for reviewing this patch! FWIW, the type of _mutex is Monitor* in MonitorLocker object. `static_cast` just makes use that. Arbitrary casting is error-prone, but this is not the case. ------------- PR: https://git.openjdk.java.net/jdk/pull/3350 From iklam at openjdk.java.net Tue Apr 6 18:06:54 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Apr 2021 18:06:54 GMT Subject: RFR: 8264797: Do not include klassVtable.hpp from instanceKlass.hpp Message-ID: instanceKlass.hpp is a popular header, included by 647 of about 1000 HotSpot .o files. It unnecessarily includes klassVtable.hpp (only forward class declarations are needed). After refactoring, the number of .o files that includes klassVtable.hpp reduces from 647 to 132. ------------- Commit messages: - 8264797: Do not include klassVtable.hpp from instanceKlass.hpp Changes: https://git.openjdk.java.net/jdk/pull/3360/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3360&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264797 Stats: 6 lines in 5 files changed: 5 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3360.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3360/head:pull/3360 PR: https://git.openjdk.java.net/jdk/pull/3360 From pchilanomate at openjdk.java.net Tue Apr 6 18:40:29 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 6 Apr 2021 18:40:29 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 08:27:35 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn 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 SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - 8257831: Suspend with handshake (review baseline) src/hotspot/share/runtime/handshake.hpp line 122: > 120: // must take slow path, process_by_self(), if _lock is held. > 121: bool should_process() { > 122: return !_queue.is_empty() || _lock.is_locked(); While trying to think of the objectMonitor case I realize the order of this should probably be reversed with a load fence in between. Otherwise we could have the following scenario: Thread A blocks in ~ThreadInVMfromJava() -> wait_for_object_deoptimization() with _thread_blocked state. Thread Z executes SuspendThreadHandshake on A. Gets context switched before adding the async handshake. Thread A unblocks and transitions back to _thread_in_java. Calls SafepointMechanism::process_if_requested()-> process_if_requested_slow() since poll is armed. Checks that the handshake queue is empty. Gets context switched. Thread Z installs async handshake in queue, releases _lock and continues. Thread A checks _lock is unlocked so it doesn't call HandshakeState::process_by_self() to suspend and continues back to Java. (Poll will still be armed though because we will see it in update_poll_values()). ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Tue Apr 6 18:51:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 6 Apr 2021 18:51:42 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 12:22:42 GMT, Robbin Ehn wrote: >> Sure. I agree with your comment. > > I think we should add JVMTI_ERROR_THREAD_SUSPENDED as @reinrich says, it is possible for someone to sneak in a second suspend request before us. > > @dcubed-ojdk it seem like we could be posting JvmtiExport::post_monitor_contended_enter() from the ensure_join() which locks the threadObj. > > So it might be best to treat this the same way as the others? By "treat this the same way as the others", you mean check and return either JVMTI_ERROR_THREAD_NOT_ALIVE or JVMTI_ERROR_THREAD_SUSPENDED as appropriate when we get a false back from JvmtiSuspendControl::suspend(current)? I'm not sure what this question is about: > it seem like we could be posting JvmtiExport::post_monitor_contended_enter() from the ensure_join() which locks the threadObj. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From sspitsyn at openjdk.java.net Tue Apr 6 19:00:43 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 6 Apr 2021 19:00:43 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 11:09:52 GMT, Robbin Ehn wrote: >> Hi Robbin, >> >> This is a great piece of work with a lot of code simplifications. Unfortunately some new complexities that need to be hidden by appropriate abstractions. Lots of comments, queries and suggestions below. >> >> Thanks, >> David > >> Hi Robbin, >> >> This is a great piece of work with a lot of code simplifications. Unfortunately some new complexities that need to be hidden by appropriate abstractions. Lots of comments, queries and suggestions below. >> >> Thanks, >> David > > Thanks David! Hi Robbin, I'm looking at it. I have a concern that it can significantly impact Loom implementation. There is a non-trivial update in Loom to support virtual threads in JVMTI Suspend/Resume. So we need to make sure your approach is going to work for virtual threads as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Tue Apr 6 19:00:43 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 6 Apr 2021 19:00:43 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: <3R504XyTsO1yytT_Mkt9EU1JFSP91nUdjtl0njFZFzw=.a0794436-09de-448a-b53e-8eb36c5a481f@github.com> References: <3R504XyTsO1yytT_Mkt9EU1JFSP91nUdjtl0njFZFzw=.a0794436-09de-448a-b53e-8eb36c5a481f@github.com> Message-ID: <9FA4KeXipEhxHnc_K8tpPPejVz3oj_MCzvn9iIhR554=.dae67fa0-9218-49a7-9062-74d082d4e35b@github.com> On Tue, 6 Apr 2021 13:06:39 GMT, Robbin Ehn wrote: >> These `Threads_lock NOT held ...` comments in JVM/TI are a left over >> issue from the Thread-SMR project and I think I forgot to file a follow-up >> bug to clean those up. >> >> I recommend handling that in a general cleanup issue for all of these >> comments in JVM/TI (and possibly elsewhere). Please let me know if I >> should go ahead and file that bug. > > Yes, please file that issue. Done. I filed: JDK-8264800 cleanup Threads_lock comments in JVM/TI function headers ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From coleenp at openjdk.java.net Tue Apr 6 19:26:31 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 6 Apr 2021 19:26:31 GMT Subject: RFR: 8264797: Do not include klassVtable.hpp from instanceKlass.hpp In-Reply-To: References: Message-ID: <8eQJFKak3RWxOazHS9uJJO6AZjwi3ogfFs7PoEGFU9E=.d8eb5d61-9b49-4fcd-9212-173c24d33909@github.com> On Tue, 6 Apr 2021 17:07:23 GMT, Ioi Lam wrote: > instanceKlass.hpp is a popular header, included by 647 of about 1000 HotSpot .o files. It unnecessarily includes klassVtable.hpp (only forward class declarations are needed). > > After refactoring, the number of .o files that includes klassVtable.hpp reduces from 647 to 132. I thought you'd need to include the file because of this, because it's not a pointer: klassItable itable() const; // return klassItable wrapper That's good that you don't! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3360 From iklam at openjdk.java.net Tue Apr 6 19:53:16 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Apr 2021 19:53:16 GMT Subject: RFR: 8264797: Do not include klassVtable.hpp from instanceKlass.hpp In-Reply-To: <8eQJFKak3RWxOazHS9uJJO6AZjwi3ogfFs7PoEGFU9E=.d8eb5d61-9b49-4fcd-9212-173c24d33909@github.com> References: <8eQJFKak3RWxOazHS9uJJO6AZjwi3ogfFs7PoEGFU9E=.d8eb5d61-9b49-4fcd-9212-173c24d33909@github.com> Message-ID: On Tue, 6 Apr 2021 19:23:07 GMT, Coleen Phillimore wrote: > I thought you'd need to include the file because of this, because it's not a pointer: > klassItable itable() const; // return klassItable wrapper > > That's good that you don't! Thanks for the review. I looked this up to make sure what I am doing is allowed. Accord to the C++ specification, a forward-declared class is an incomplete type, which cannot be used "_in general, when the size and layout of the type must be known_". In this case, we just have a declaration of a function, so an incomplete type is allowed. - https://en.cppreference.com/w/cpp/language/class - https://en.cppreference.com/w/cpp/language/type#Incomplete_type ------------- PR: https://git.openjdk.java.net/jdk/pull/3360 From stefank at openjdk.java.net Tue Apr 6 20:07:21 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 6 Apr 2021 20:07:21 GMT Subject: RFR: 8264797: Do not include klassVtable.hpp from instanceKlass.hpp In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 17:07:23 GMT, Ioi Lam wrote: > instanceKlass.hpp is a popular header, included by 647 of about 1000 HotSpot .o files. It unnecessarily includes klassVtable.hpp (only forward class declarations are needed). > > After refactoring, the number of .o files that includes klassVtable.hpp reduces from 647 to 132. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3360 From jiefu at openjdk.java.net Tue Apr 6 23:08:22 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 6 Apr 2021 23:08:22 GMT Subject: RFR: 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to swapping not working [v3] In-Reply-To: References: Message-ID: <6loPE_R0yKDapUWcwKJCdI92pdcwkgRC9h3bKQMeW6I=.db8fb398-ec9d-4e38-b47c-d26780c8353b@github.com> On Tue, 6 Apr 2021 13:45:27 GMT, Severin Gehwolf wrote: > LGTM. Thanks @jerboaa for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3286 From jiefu at openjdk.java.net Tue Apr 6 23:08:23 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 6 Apr 2021 23:08:23 GMT Subject: Integrated: 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to swapping not working In-Reply-To: References: Message-ID: <5Xcadc71oqXzRZq57Q19A7M8U71uDAR0NXm2axb2c8E=.5e333203-b761-4002-83ab-6f844372e9ab@github.com> On Wed, 31 Mar 2021 15:53:28 GMT, Jie Fu wrote: > Hi all, > > jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails on some of our testing platforms. > This is because testMemoryFailCount [1] fails due to OOM killed. > This test fails to avoid OOM killed [2] if memory.failcnt is always 0. > > The fix will print "Not OOM killed" if OOM killed doesn't happen. > And also fix another bug if the test get returned here [3]. > > Testing: > - jdk/internal/platform/docker/ hotspot/jtreg/containers on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java#L80 > [2] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L87 > [3] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L96 This pull request has now been integrated. Changeset: bfb034ab Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/bfb034ab Stats: 25 lines in 1 file changed: 23 ins; 0 del; 2 mod 8264524: jdk/internal/platform/docker/TestDockerMemoryMetrics.java fails due to swapping not working Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/3286 From ysuenaga at openjdk.java.net Wed Apr 7 00:16:26 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 7 Apr 2021 00:16:26 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v3] In-Reply-To: References: <07xszQhnfsbFlftK7fHgoFGVRhG9m_IPPUOg1-j120M=.7ae018d5-227e-448a-ad13-913c1ecd2ff1@github.com> Message-ID: On Tue, 6 Apr 2021 14:58:56 GMT, Gerard Ziemski wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Use functions in os class > > Marked as reviewed by gziemski (Committer). Thanks @gerard-ziemski ! @theRealAph @shipilev How about this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From iklam at openjdk.java.net Wed Apr 7 03:48:30 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 7 Apr 2021 03:48:30 GMT Subject: RFR: 8264797: Do not include klassVtable.hpp from instanceKlass.hpp In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 20:04:38 GMT, Stefan Karlsson wrote: >> instanceKlass.hpp is a popular header, included by 647 of about 1000 HotSpot .o files. It unnecessarily includes klassVtable.hpp (only forward class declarations are needed). >> >> After refactoring, the number of .o files that includes klassVtable.hpp reduces from 647 to 132. > > Marked as reviewed by stefank (Reviewer). Thanks @stefank and @coleenp for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3360 From iklam at openjdk.java.net Wed Apr 7 03:48:31 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 7 Apr 2021 03:48:31 GMT Subject: Integrated: 8264797: Do not include klassVtable.hpp from instanceKlass.hpp In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 17:07:23 GMT, Ioi Lam wrote: > instanceKlass.hpp is a popular header, included by 647 of about 1000 HotSpot .o files. It unnecessarily includes klassVtable.hpp (only forward class declarations are needed). > > After refactoring, the number of .o files that includes klassVtable.hpp reduces from 647 to 132. This pull request has now been integrated. Changeset: c3abdc9a Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/c3abdc9a Stats: 6 lines in 5 files changed: 5 ins; 1 del; 0 mod 8264797: Do not include klassVtable.hpp from instanceKlass.hpp Reviewed-by: coleenp, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/3360 From dholmes at openjdk.java.net Wed Apr 7 04:25:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Apr 2021 04:25:42 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 18:47:58 GMT, Daniel D. Daugherty wrote: >> I think we should add JVMTI_ERROR_THREAD_SUSPENDED as @reinrich says, it is possible for someone to sneak in a second suspend request before us. >> >> @dcubed-ojdk it seem like we could be posting JvmtiExport::post_monitor_contended_enter() from the ensure_join() which locks the threadObj. >> >> So it might be best to treat this the same way as the others? > > By "treat this the same way as the others", you mean check and return either > JVMTI_ERROR_THREAD_NOT_ALIVE or JVMTI_ERROR_THREAD_SUSPENDED as > appropriate when we get a false back from JvmtiSuspendControl::suspend(current)? > > I'm not sure what this question is about: > >> it seem like we could be posting JvmtiExport::post_monitor_contended_enter() from the ensure_join() which locks the threadObj. I'm also unclear what Robbin is referring to. I go back to my original comment that surely JVMTI_ERROR_THREAD_NOT_ALIVE is impossible here? ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From david.holmes at oracle.com Wed Apr 7 05:00:50 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Apr 2021 15:00:50 +1000 Subject: RFR: 8264482: container info misleads on non-container environment [v2] In-Reply-To: References: <3xBZarV2-nFsRCB-iCLzNSE4H316QbfeZ61MHywMV9E=.215d64c5-1ad2-41df-926d-10941b734b3b@github.com> Message-ID: <816098c8-72d9-bb1b-393d-d76c1fcd6309@oracle.com> On 6/04/2021 10:09 pm, Yasumasa Suenaga wrote: > On Tue, 6 Apr 2021 10:06:18 GMT, Severin Gehwolf wrote: > >> What I'm unsure about is whether or not this is a problem worth fixing. > > I think fundamental solutions will be implemented in JDK-8261242, but It seems to be a difficult task. > >> The main idea is abstraction from cgroups in the container code. It does say `container (cgroup) information` in the heading. > > I know that, but "container_type" label is in hs_err / VM.info log. In addition, UL reports some metrics as "container" in spite of cgroups. > If it takes a long time to fix JDK-8261242, I want to fix log messages for cgroups for next LTS release at least. "container" messages may make the customer do extra work to collect / analyzer their system. Then can we compromise and just say "container/cgroup" everywhere? David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3280 > From david.holmes at oracle.com Wed Apr 7 05:21:06 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Apr 2021 15:21:06 +1000 Subject: RFR: 8264682: MemProfiling does not own Heap_lock when using G1 In-Reply-To: References: Message-ID: On 7/04/2021 12:34 am, Coleen Phillimore wrote: > On Tue, 6 Apr 2021 02:04:57 GMT, David Holmes wrote: > >>> Trivial fix for JDK-8264682. >>> >>> `Universe::heap()->used()` calls G1Allocator::used_in_alloc_regions() when G1 enabled, it checks whether Heap_lock was owned on this thread's behalf. >> >> Sorry but I have to agree with Kim that this is the wrong fix for this problem. >> >> And the test needs adjusting. >> >> Thanks, >> David > > Unless we can imagine a reason why this code is needed, I think the old memprofiler should be removed. Why was it added? I've no idea who might be using this, or for what. But I think removing it is a separate issue. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3340 > From dholmes at openjdk.java.net Wed Apr 7 05:29:40 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Apr 2021 05:29:40 GMT Subject: RFR: 8264731: Introduce InstanceKlass::method_at_itable_or_null() [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 13:01:53 GMT, Vladimir Ivanov wrote: >> Introduce `InstanceKlass::method_at_itable_or_null()` - a non-throwing variant of `InstanceKlass::method_at_itable()` that implements interface method selection. >> >> As a cleanup, rewrite `InstanceKlass::method_at_itable()` on top of `InstanceKlass::method_at_itable_or_null()`. >> >> Testing: >> * [x] hs-tier1 - hs-tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Cleanups Update looks good - thanks - but I'd like to see it extend a little further. Thanks, David src/hotspot/share/oops/instanceKlass.cpp line 3180: > 3178: } > 3179: > 3180: Method* InstanceKlass::method_at_itable_or_null(InstanceKlass* holder, int index, bool& itable_entry_found) { The change to use implements_interface applies in here too. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3344 From dholmes at openjdk.java.net Wed Apr 7 05:35:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Apr 2021 05:35:36 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 13:41:48 GMT, Vladimir Ivanov wrote: >> Turn `resolved_method` parameter into raw `Method*`. >> >> Testing: >> * [x] hs-tier1 - hs-tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Revert jvmciCompilerToVM.cpp change. Seems quite reasonable - though unsure of the motivation. Do we need a NoSafepointVerifier in LinkResolver::vtable_index_of_interface_method to ensure the raw Method* remains valid? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3346 From ccheung at openjdk.java.net Wed Apr 7 05:38:25 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 7 Apr 2021 05:38:25 GMT Subject: RFR: 8214455: Relocate CDS archived regions to the top of the G1 heap [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 17:04:18 GMT, Ioi Lam wrote: >> When the runtime heap and dump time heap have different sizes, it's possible that the archived heap regions are mapped to the middle of the runtime heap. Because the archived heap regions are pinned, this could reduce the size of the largest "humongous" array allocation. In the worst case, the maximum allocatable array length may be half of the optimal value. >> >> The fix is to relocate the archived regions to the top of the G1 heap (currently archived regions are supported only by G1 on 64-bit JVM). >> >> Note that usually the top of the G1 heap is placed just below the 32GB boundary. As a result, the archived heap regions are at the same location between run time and dump time, so no relocation is necessary. >> >> In mach5 testing, we occasionally run into this problem (see https://bugs.openjdk.java.net/browse/JDK-8239089), probably because we fail to reserve the heap below 32GB due to address space layout randomization (ASLR). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @tschatzl review -- fix typos and whitespace Looks good. Just one minor nit in the test case. test/hotspot/jtreg/runtime/cds/appcds/cacheObject/HeapFragmentationTest.java line 84: > 82: // Run with CDS. The archived heap regions should be relocated to avoid fragmentation. > 83: TestCommon.run(TestCommon.concat(execArgs, runTimeHeapSize, mainClass, BUFF_SIZE)) > 84: .assertNormalExit(successOutput); The assertNormalExit line should be indented four spaces relative to the previous line. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3349 From dholmes at openjdk.java.net Wed Apr 7 05:39:38 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Apr 2021 05:39:38 GMT Subject: RFR: 8264742: member variable _monitor of MonitorLocker is redundant In-Reply-To: References: Message-ID: <_SGh6zD4O4eZFVpfm5Po55ySRivKZFQ4imxur4jSOfQ=.437f36bb-cce7-4ef7-920e-2f2cc8214d7c@github.com> On Tue, 6 Apr 2021 04:05:21 GMT, Xin Liu wrote: > MonitorLocker is a subclass of MutexLocker. The member variable _monitor > has the same value of _mutex in its base class. Thanks for the additional investigation of the code generation - much appreciated. Changes look good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3350 From rehn at openjdk.java.net Wed Apr 7 06:57:38 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 06:57:38 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> <1ezluoPSA1_4PpSyTQKh2dNkBMGMTtlEg3BEzFxCLEo=.36b8a600-8148-4bfb-b8d7-1393b8cf29d7@github.com> Message-ID: On Tue, 6 Apr 2021 17:27:15 GMT, Patricio Chilano Mateo wrote: >>> Also when the suspend request happened while A was blocked then after >>> current->set_thread_state_fence(_thread_blocked_trans); the check of >>> is_suspended() will return true even if the handshake state lock is not >>> acquired for the check >> >> That statement of mine is wrong. (Hopefully) correct is that after the complete >> state change from _thread_blocked to _thread_in_vm which includes being blocked >> for a safepoint/handshake the current thread would be able to check >> is_suspended() without holding the handshake state lock. It does not make a lot >> of sense then because in an unsafe state JavaThread::current()->is_suspended() >> will always return false. >> >>> Thread A wait on OM X in blocked. >>> Thread Z suspends Thread A, thread Z have no relation to OM X. >>> Thread B unlocks OM X, thread B have no relation to the suspend request. >>> Thread A locks OM X while blocked. >>> Thread A was not allowed to lock OM X due to it is actually suspended. >>> Thread A unlocks OM X and waits until resumed. >> >> I understand that example now too: OM and suspend operations are unrelated. So I >> thought it would be ok for A to enter OM X, but it is not. A thread must not >> leave a safe state if it was suspended in that state (with a handshake). If it >> did, e.g., its stack could become not walkable. And it must not enter the >> monitor either. >> >> Sorry for the confusion. The check is good. > > But I still think we can just call is_suspended() here. If is_suspended() returns false, then Z hasn't finished suspending A yet (either async operation was still not added to the queue in case this is the first suspend for A, or do_handshake() hasn't yet finished for that SuspendThreadHandshake operation in case there was already an async operation in the queue). Since we have already acquired OM, then Z will not see that after being suspended A switched from not owning OM to owning it. It will always see that A owned OM. And A will still block for the suspension in the 'else' clause since poll is armed due to SuspendThreadHandshake operation(even if async operation was still not added to the queue at the time A called is_suspended()), but we wouldn't need to release OM. > If is_suspended() returns true then at most we will have a false positive, since it could be that after the check somebody already resumed A, but that can also happen even with suspend_request_pending() right after releasing HandshakeState::_lock. > Is that correct or am I missing something? I'm not saying it doesn't work, I'm saying it works by accident (I never intended to be able to read the flag without HandshakeState lock). So yes, if the flag is false (lockless read), it is not possible for the suspend to have happened before we locked the OM. And once poll is armed for the synchrone handshake it will stay armed until after we executed the asynchrone handshake trap. What is possible is that we have armed for the suspend but not yet set the flag. If we consider the flag as the tipping point and not the start of execution of the suspend sync handshake, we can do the lockless read. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 07:08:39 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 07:08:39 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 04:22:21 GMT, David Holmes wrote: >> By "treat this the same way as the others", you mean check and return either >> JVMTI_ERROR_THREAD_NOT_ALIVE or JVMTI_ERROR_THREAD_SUSPENDED as >> appropriate when we get a false back from JvmtiSuspendControl::suspend(current)? >> >> I'm not sure what this question is about: >> >>> it seem like we could be posting JvmtiExport::post_monitor_contended_enter() from the ensure_join() which locks the threadObj. > > I'm also unclear what Robbin is referring to. I go back to my original comment that surely JVMTI_ERROR_THREAD_NOT_ALIVE is impossible here? We do a callback with a terminated thread, if the thread then in the agent tries to suspend itself we should return JVMTI_ERROR_THREAD_NOT_ALIVE. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 07:16:43 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 07:16:43 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 03:59:35 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 319: > >> 317: jt = self->as_Java_thread(); >> 318: while (true) { >> 319: // To pause suspend requests while in native we must block handshakes. > > The earlier comment says we must be _thread_blocked in this code, so we won't be "native". But that is not a _thread_blocked that is managed by a thread-state transition so that is why this code has to "manually" manage the handshake state. Fixed comment ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 07:23:32 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 07:23:32 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 04:56:32 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 428: > >> 426: jt->set_thread_state_fence(_thread_in_native_trans); >> 427: SafepointMechanism::process_if_requested(jt); >> 428: if (jt->is_interrupted(true)) { > > A thread must be _thread_in_vm to safely query is_interrupted() as it accesses the threadObj. Any unsafe (not native/blocked) is fine, therefore I never completed the transition. I set the state to _thread_in_vm before. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From ysuenaga at openjdk.java.net Wed Apr 7 07:26:27 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 7 Apr 2021 07:26:27 GMT Subject: RFR: 8264482: container info misleads on non-container environment [v2] In-Reply-To: References: <3xBZarV2-nFsRCB-iCLzNSE4H316QbfeZ61MHywMV9E=.215d64c5-1ad2-41df-926d-10941b734b3b@github.com> Message-ID: On Tue, 6 Apr 2021 12:06:37 GMT, Yasumasa Suenaga wrote: >> @YaSuenag Unfortunately that's the status quo, yes. On a plain linux system without cgroup limits for the java process, but with the cgroup subsystem mounted, it'll report some cgroup (container) metrics (same as the host values, though). What I'm unsure about is whether or not this is a problem worth fixing. The main idea is abstraction from cgroups in the container code. It does say `container (cgroup) information` in the heading. > >> What I'm unsure about is whether or not this is a problem worth fixing. > > I think fundamental solutions will be implemented in JDK-8261242, but It seems to be a difficult task. > >> The main idea is abstraction from cgroups in the container code. It does say `container (cgroup) information` in the heading. > > I know that, but "container_type" label is in hs_err / VM.info log. In addition, UL reports some metrics as "container" in spite of cgroups. > If it takes a long time to fix JDK-8261242, I want to fix log messages for cgroups for next LTS release at least. "container" messages may make the customer do extra work to collect / analyzer their system. > Then can we compromise and just say "container/cgroup" everywhere? How about following change? It is easy to add new resource controller other than cgroups in future. // get_resource_container_name() will return "cgroups" or "cgroupsV2" const char *resource_controller_name = OSContainer::get_resource_container_name(); log_debug(os, container)("%s memory limit %s: " JLONG_FORMAT ", using host value", resource_controller_name, mem_limit == OSCONTAINER_ERROR ? "failed" : "unlimited", mem_limit); ------------- PR: https://git.openjdk.java.net/jdk/pull/3280 From rehn at openjdk.java.net Wed Apr 7 07:28:48 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 07:28:48 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 05:21:03 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.cpp line 463: > >> 461: ThreadInVMForHandshake tivm(_handshakee); >> 462: { >> 463: ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); > > Why is this needed when it is inside ThreadInVMForHandshake constructor ?? If we process the async suspension handshake we can go to safepoint. And before safepoint we must drop the tty lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 07:28:45 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 07:28:45 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 05:03:47 GMT, David Holmes 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.cpp line 415: > >> 413: // Adds are done lock free and so is arming. >> 414: // Calling this method with lock held is considered an error. >> 415: assert(!_lock.owned_by_self(), "Lock should not be held"); > > If adds are still lock-free then why was this assertion removed? Because we add the async handshake inside the sync handshake and thus we already hold the _lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From david.holmes at oracle.com Wed Apr 7 07:36:06 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Apr 2021 17:36:06 +1000 Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <1bcc8caa-6353-7b16-4e46-0388e8d3c1de@oracle.com> On 7/04/2021 5:08 pm, Robbin Ehn wrote: > On Wed, 7 Apr 2021 04:22:21 GMT, David Holmes wrote: > >>> By "treat this the same way as the others", you mean check and return either >>> JVMTI_ERROR_THREAD_NOT_ALIVE or JVMTI_ERROR_THREAD_SUSPENDED as >>> appropriate when we get a false back from JvmtiSuspendControl::suspend(current)? >>> >>> I'm not sure what this question is about: >>> >>>> it seem like we could be posting JvmtiExport::post_monitor_contended_enter() from the ensure_join() which locks the threadObj. >> >> I'm also unclear what Robbin is referring to. I go back to my original comment that surely JVMTI_ERROR_THREAD_NOT_ALIVE is impossible here? > > We do a callback with a terminated thread, if the thread then in the agent tries to suspend itself we should return JVMTI_ERROR_THREAD_NOT_ALIVE. How can you do a callback on a terminated thread here? The thread should only respond to the suspend request before it reaches the point in its exit where it would report "not alive". David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3191 > From rehn at openjdk.java.net Wed Apr 7 07:37:34 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 07:37:34 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 05:38:14 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.cpp line 633: > >> 631: bool HandshakeState::suspend_request_pending() { >> 632: assert(JavaThread::current()->thread_state() != _thread_blocked, "should not be in a blocked state"); >> 633: assert(JavaThread::current()->thread_state() != _thread_in_native, "should not be in native"); > > Not clear why we care about the state of the current thread here ?? I missed one assert, this must be asked on yourself. If you ask while in blocked/native the answer may change at any moment, since processing of handshake is ok. To get a stable result you must be in another state. Note @pchilano think we should remove this method, so either I add assert and comment or remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From david.holmes at oracle.com Wed Apr 7 07:40:01 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Apr 2021 17:40:01 +1000 Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <3bf9c296-8c9c-89af-87f7-29bc16d2d55b@oracle.com> On 7/04/2021 5:37 pm, Robbin Ehn wrote: > On Wed, 31 Mar 2021 05:38:14 GMT, David Holmes 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 two commits: >>> >>> - Merge branch 'master' into SuspendInHandshake >>> - 8257831: Suspend with handshake (review baseline) >> >> src/hotspot/share/runtime/handshake.cpp line 633: >> >>> 631: bool HandshakeState::suspend_request_pending() { >>> 632: assert(JavaThread::current()->thread_state() != _thread_blocked, "should not be in a blocked state"); >>> 633: assert(JavaThread::current()->thread_state() != _thread_in_native, "should not be in native"); >> >> Not clear why we care about the state of the current thread here ?? > > I missed one assert, this must be asked on yourself. > If you ask while in blocked/native the answer may change at any moment, since processing of handshake is ok. > To get a stable result you must be in another state. My point was more, shouldn't we be querying the state of the handshakee? The current thread's state can't change "at any moment". David > Note @pchilano think we should remove this method, so either I add assert and comment or remove it. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3191 > From rehn at openjdk.java.net Wed Apr 7 08:06:59 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 08:06:59 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 07:04:50 GMT, Robbin Ehn wrote: >> I'm also unclear what Robbin is referring to. I go back to my original comment that surely JVMTI_ERROR_THREAD_NOT_ALIVE is impossible here? > > We do a callback with a terminated thread, if the thread then in the agent tries to suspend itself we should return JVMTI_ERROR_THREAD_NOT_ALIVE. "How can you do a callback on a terminated thread here? The thread should only respond to the suspend request before it reaches the point in its exit where it would report "not alive"." We need to keep the threadObj while we are not terminated. When terminated we need to clear threadObj and notify any waiters. ObjectLocker executes OM::enter(), on contention OM::enter() do a callback to your agent. If you on that callback execute suspendThreadList(), the correct return value for: `"JvmtiSuspendControl::suspend(current)"` would be JVMTI_ERROR_THREAD_NOT_ALIVE, since JavaThread::is_exiting() would return true here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 08:24:36 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 08:24:36 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 15:50:56 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/objectMonitor.cpp line 973: > >> 971: if (SafepointMechanism::should_process(current)) { >> 972: if (_succ == current) { >> 973: _succ = NULL; > > IIUC then this is now not only executed if a thread is suspended but also when there's a safepoint / handshake. I tried to understand the effect of this but failed with timeout ;) On high-level clearing causes some extra work and contention when exiting. Maybe we should think about just doing this when suspended. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From aph at openjdk.java.net Wed Apr 7 08:36:27 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 7 Apr 2021 08:36:27 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v3] In-Reply-To: References: <-Nst2cJnAG4QOBm6mOzLgpnbHIuUapDYuSjVl0jZZso=.40ec4b9e-0008-40cd-b9de-cdbe37a7000e@github.com> <0yqu_5IhRCJBjDLC4Nu3bg6i7yjADxS2Cu3C_IRaoF4=.5fa9d572-563d-44da-8261-78ee566b9d8a@github.com> Message-ID: On Wed, 31 Mar 2021 13:31:19 GMT, Yasumasa Suenaga wrote: >> One other thing I missed last time around: why is there a permanently-allocated 4k buffer for this code that it only used for jfr? > > I pushed new commit with some refactoring. > >> Please be more explicit. This is (perhaps obviously?) a workaround for a bug, And t.his code is itself a bug, because it doesn't check for the condition you care about. So, please check explicitly for this condition: \n only, and nothing else. And leave a comment explaining why. > > I've done so in new commit. > >> One other thing I missed last time around: why is there a permanently-allocated 4k buffer for this code that it only used for jfr? > > Some features (e.g. hs_err log, VM.info dcmd) dumps /proc/cpuinfo, so I guess this feature is used JFR only now. However CPU description has different information (for AArch64 at least), so we might be able to use it in other place, but it is out of scope this PR. Looks better. I guess the problem here is that we don't know how robust we need to make this against future bugs. Maybe we should just concatenate all three files? ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From rehn at openjdk.java.net Wed Apr 7 08:37:33 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 08:37:33 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:08:49 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/objectMonitor.cpp line 411: > >> 409: OrderAccess::storestore(); >> 410: for (;;) { >> 411: current->set_thread_state(_thread_blocked); > > So IIUC because ThreadblockInVM is now responsible for handling thread suspension checks, but those checks need to be done at a lower level, we can no longer use ThreadBlockInVM in some places. That both undermines the value of ThreadBlockInVM and make this manual management code much more complex. > I agree with Richard that a TBIVM that took an unlock function would make this kind of code much clearer. The problem is the we lock the OM from blocked state and then regret it. Since we should not execute 'bytecode' during safe state but this implementation does that we end up in this mess. If this implementation did the correct thing we could use ThreadblockInVM straight forward. As I suggested if we are only blocked around parker it fixes it. The reason for grabbing the lock is that we cannot call exit on the OM which wakes next thread. Only the owner may call exit, this makes succession more complicate because you might wake a suspended thread. Now the suspended thread needs to wake another thread without owning the lock. And yes adding a method ThreadBlockInVM can help here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 08:44:41 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 08:44:41 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 05:57:30 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/nonJavaThread.cpp line 326: > >> 324: >> 325: while (watcher_thread() != NULL) { >> 326: // This wait should make safepoint checks, wait without a timeout. > > Nit: s/checks, wait/checks and wait/ Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From yyang at openjdk.java.net Wed Apr 7 09:36:29 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 7 Apr 2021 09:36:29 GMT Subject: RFR: 8264682: MemProfiling does not own Heap_lock when using G1 In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 14:31:00 GMT, Coleen Phillimore wrote: >> Sorry but I have to agree with Kim that this is the wrong fix for this problem. >> >> And the test needs adjusting. >> >> Thanks, >> David > > Unless we can imagine a reason why this code is needed, I think the old memprofiler should be removed. I'd like to propose a new PR to remove the memprofiler if there are no strong objections. ------------- PR: https://git.openjdk.java.net/jdk/pull/3340 From david.holmes at oracle.com Wed Apr 7 09:45:41 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Apr 2021 19:45:41 +1000 Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <93083fec-a0b8-5f64-f398-e3b1593825f9@oracle.com> On 7/04/2021 6:06 pm, Robbin Ehn wrote: > On Wed, 7 Apr 2021 07:04:50 GMT, Robbin Ehn wrote: > >>> I'm also unclear what Robbin is referring to. I go back to my original comment that surely JVMTI_ERROR_THREAD_NOT_ALIVE is impossible here? >> >> We do a callback with a terminated thread, if the thread then in the agent tries to suspend itself we should return JVMTI_ERROR_THREAD_NOT_ALIVE. > > "How can you do a callback on a terminated thread here? The thread should > only respond to the suspend request before it reaches the point in its > exit where it would report "not alive"." > > We need to keep the threadObj while we are not terminated. > When terminated we need to clear threadObj and notify any waiters. > ObjectLocker executes OM::enter(), on contention OM::enter() do a callback to your agent. > If you on that callback execute suspendThreadList(), the correct return value for: > `"JvmtiSuspendControl::suspend(current)"` would be JVMTI_ERROR_THREAD_NOT_ALIVE, since JavaThread::is_exiting() would return true here. Sorry yes I see what you mean. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3191 > From david.holmes at oracle.com Wed Apr 7 09:54:27 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Apr 2021 19:54:27 +1000 Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <789bc7b1-273c-bcab-4c85-6692445b934e@oracle.com> On 7/04/2021 6:37 pm, Robbin Ehn wrote: > On Wed, 31 Mar 2021 06:08:49 GMT, David Holmes 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 two commits: >>> >>> - Merge branch 'master' into SuspendInHandshake >>> - 8257831: Suspend with handshake (review baseline) >> >> src/hotspot/share/runtime/objectMonitor.cpp line 411: >> >>> 409: OrderAccess::storestore(); >>> 410: for (;;) { >>> 411: current->set_thread_state(_thread_blocked); >> >> So IIUC because ThreadblockInVM is now responsible for handling thread suspension checks, but those checks need to be done at a lower level, we can no longer use ThreadBlockInVM in some places. That both undermines the value of ThreadBlockInVM and make this manual management code much more complex. >> I agree with Richard that a TBIVM that took an unlock function would make this kind of code much clearer. > > The problem is the we lock the OM from blocked state and then regret it. > Since we should not execute 'bytecode' during safe state but this implementation does that we end up in this mess. > If this implementation did the correct thing we could use ThreadblockInVM straight forward. > As I suggested if we are only blocked around parker it fixes it. Pushing the thread-state transition closer to the actual part where we park/block might seem to avoid this issue, but if we were unparked and find ourselves suspended then we still have to wake another waiter, which we aren't allowed to do without owning the lock so ... > The reason for grabbing the lock is that we cannot call exit on the OM which wakes next thread. > Only the owner may call exit, this makes succession more complicate because you might wake a suspended thread. > Now the suspended thread needs to wake another thread without owning the lock. ... moving the scope of the TBIVM doesn't fix it. You've made the TBIVM responsible in part for suspension checks but the scope of the TBIVM as used and the scope where we need suspension checks don't match. > And yes adding a method ThreadBlockInVM can help here. So bottom line is that we can define a new TBIVM that can work in these cases and hide all the explicit state machinations? Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3191 > From rrich at openjdk.java.net Wed Apr 7 09:59:39 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 7 Apr 2021 09:59:39 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 08:27:35 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn 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 SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - 8257831: Suspend with handshake (review baseline) src/hotspot/share/runtime/objectMonitor.cpp line 428: > 426: } else { > 427: // Only exit path from for loop > 428: SafepointMechanism::process_if_requested(current); I think the current thread can suspend here in L428. This seems problematic as entering OM has been started but not completed. - The current thread is set as owner in ObjectMonitor::_owner - The thread state will still be JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER because of the JavaThreadBlockedOnMonitorEnterState in L389. - Thread::_current_pending_monitor has not been reset to NULL. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rrich at openjdk.java.net Wed Apr 7 10:53:33 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 7 Apr 2021 10:53:33 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: <4uRXV4EtReASGHnfiURatSQEaVR1AJEXyYAkDqbuqp4=.0740be86-2715-4f68-8e35-e3f4811b839f@github.com> <1ezluoPSA1_4PpSyTQKh2dNkBMGMTtlEg3BEzFxCLEo=.36b8a600-8148-4bfb-b8d7-1393b8cf29d7@github.com> Message-ID: <_RUR1QW_lPYryjMWvX15yX2-ivm9kUH28S3JWovYOZ8=.6d8e5bc2-2e5a-44a5-b6de-567e9582fe8d@github.com> On Wed, 7 Apr 2021 06:51:22 GMT, Robbin Ehn wrote: >> But I still think we can just call is_suspended() here. If is_suspended() returns false, then Z hasn't finished suspending A yet (either async operation was still not added to the queue in case this is the first suspend for A, or do_handshake() hasn't yet finished for that SuspendThreadHandshake operation in case there was already an async operation in the queue). Since we have already acquired OM, then Z will not see that after being suspended A switched from not owning OM to owning it. It will always see that A owned OM. And A will still block for the suspension in the 'else' clause since poll is armed due to SuspendThreadHandshake operation(even if async operation was still not added to the queue at the time A called is_suspended()), but we wouldn't need to release OM. >> If is_suspended() returns true then at most we will have a false positive, since it could be that after the check somebody already resumed A, but that can also happen even with suspend_request_pending() right after releasing HandshakeState::_lock. >> Is that correct or am I missing something? > > I'm not saying it doesn't work, I'm saying it works by accident (I never intended to be able to read the flag without HandshakeState lock). > So yes, if the flag is false (lockless read), it is not possible for the suspend to have happened before we locked the OM. > And once poll is armed for the synchrone handshake it will stay armed until after we executed the asynchrone handshake trap. > > What is possible is that we have armed for the suspend but not yet set the flag. > If we consider the flag as the tipping point and not the start of execution of the suspend sync handshake, we can do the lockless read. > But I still think we can just call is_suspended() here @pchilano, potentially I had similar thoughts when I asked about it before the long weekend: the current thread will suspend either way in the then or else block if the execution of the SuspendThreadHandshake was started while the current thread was _thread_blocked. If the suspend is ordered with operations on OM then is_suspended() will return true. Otherwise it is ok to become the owner. This is a more intuitive reasoning. I prefer yours. While looking at this I noticed that suspending in L428 could be problematic because the OM is just entered half way. Maybe we could use plain ThreadBlockInVM and deal with unlocking the OM very late just before waiting in HandshakeState::suspend_in_handshake(). ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 11:46:53 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 11:46:53 GMT Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v4] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 19:46:38 GMT, Daniel D. Daugherty wrote: >> Add three tests from JDK-4413752 ported to JVM/TI: >> >> - RawMonitorEnter() with SuspendThread() >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/SuspendWithRawMonitorEnter.java >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp >> >> - ObjectMonitor enter() with SuspendThread() >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp >> >> - ObjectMonitor wait() with SuspendThread >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp >> >> The Java files have a transaction diagram to show what each of the >> threads in the test is doing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Address lyndseyBeil, robehn and sspitsyn CR comments. I really like simple agent code ?? Thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2899 From rehn at openjdk.java.net Wed Apr 7 11:52:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 11:52:19 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 09:56:19 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/objectMonitor.cpp line 428: > >> 426: } else { >> 427: // Only exit path from for loop >> 428: SafepointMechanism::process_if_requested(current); > > I think the current thread can suspend here in L428. This seems problematic as entering OM has been started but not completed. > > - The current thread is set as owner in ObjectMonitor::_owner > - The thread state will still be JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER because of the JavaThreadBlockedOnMonitorEnterState in L389. > - Thread::_current_pending_monitor has not been reset to NULL. Yes, I think you are correct. I'll look over it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 12:07:44 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 12:07:44 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 11:50:09 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 428: >> >>> 426: } else { >>> 427: // Only exit path from for loop >>> 428: SafepointMechanism::process_if_requested(current); >> >> I think the current thread can suspend here in L428. This seems problematic as entering OM has been started but not completed. >> >> - The current thread is set as owner in ObjectMonitor::_owner >> - The thread state will still be JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER because of the JavaThreadBlockedOnMonitorEnterState in L389. >> - Thread::_current_pending_monitor has not been reset to NULL. > > Yes, I think you are correct. I'll look over it. Today the ThreadBlockInVM tbivm(current); is inside scope of JavaThreadBlockedOnMonitorEnterState jtbmes(current, this);. So this can happen today also. If you are context switch just before current->set_current_pending_monitor(NULL);. Someone suspends you and look at those states. If you agree that the issue is preexisting I prefer handling that outside scope of this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 13:01:20 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 13:01:20 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 05:44:35 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.cpp line 677: > >> 675: } else { >> 676: // Target is going to wake up and leave suspension. >> 677: // Let's just stop the thread from doing that. > > IIUC this would be the case where the target was hit with a suspend request but has not yet processed the actual suspension handshake op, then a resume comes in so suspended is no longer true, and then another suspend request is made (this one) which simply turns the suspended flag back on - is that right? > Overall I'm finding it very hard to see what the two suspend state flags actually signify. I'd like to see that written up somewhere. Sure ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From coleenp at openjdk.java.net Wed Apr 7 13:04:32 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Apr 2021 13:04:32 GMT Subject: RFR: 8264682: MemProfiling does not own Heap_lock when using G1 In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 09:33:39 GMT, Yi Yang wrote: >> Unless we can imagine a reason why this code is needed, I think the old memprofiler should be removed. > > I'd like to propose a new PR to remove the memprofiler if there are no strong objections. Sure, open a new issue if you want, and link this issue to it. The "feature" was added here: ^As 00018/00000/00000 ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 ^Ac date and time created 98/04/14 13:18:32 by renes ^Ae ------------- PR: https://git.openjdk.java.net/jdk/pull/3340 From rehn at openjdk.java.net Wed Apr 7 13:05:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 13:05:19 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 05:53:43 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.hpp line 148: > >> 146: // Called from the async handshake (the trap) >> 147: // to stop a thread from continuing executing when suspended. >> 148: void suspend_in_handshake(); > > I'm finding the terminology very confusing here: handshake_suspend versus suspend_in_handshake ? It isn't at all clear which method is used in which part of the protocol. The same goes for the different closures. Fixing ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From coleenp at openjdk.java.net Wed Apr 7 13:07:02 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Apr 2021 13:07:02 GMT Subject: RFR: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out Message-ID: Added a flag so that thread 2 will notify thread 1 after it's waiting, and not before. Ran 100x on macosx-x64-debug without timeout (actually ran original 100x without timeout also). The test relies on one thread waiting at a place where another can find the class loading in progress. Alternate suggestions welcome. Thanks! Coleen ------------- Commit messages: - 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out Changes: https://git.openjdk.java.net/jdk/pull/3375/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3375&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264672 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3375.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3375/head:pull/3375 PR: https://git.openjdk.java.net/jdk/pull/3375 From rehn at openjdk.java.net Wed Apr 7 13:12:18 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 13:12:18 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:27:12 GMT, David Holmes 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/sweeper.cpp line 276: > >> 274: >> 275: ThreadBlockInVM tbivm(thread); >> 276: thread->java_suspend_self(); > > AFAICS the only change needed in this function was to delete the java_suspend_self as it is not handled in the TBIVM. Fixed > src/hotspot/share/runtime/thread.cpp line 460: > >> 458: delete metadata_handles(); >> 459: >> 460: // SR_handler uses this as a termination indicator - > > As noted previously we need a replacement for this as a proxy for a Thread (not JavaThread) terminating. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rrich at openjdk.java.net Wed Apr 7 13:12:14 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 7 Apr 2021 13:12:14 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 12:04:42 GMT, Robbin Ehn wrote: > Today the ThreadBlockInVM tbivm(current); is inside scope of JavaThreadBlockedOnMonitorEnterState jtbmes(current, this);. > So this can happen today also. > > If you are context switch just before current->set_current_pending_monitor(NULL);. > Someone suspends you and look at those states. > You mean the JVMTI agent suspends the current thread and then observes that the thread state first has the attribute JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER and in a later call it does not have it anymore (~ThreadBlockInVM doesn't check for suspend)? Yes that's problematic too. With the new code we could remain suspended with JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER. I think the OM would not be reported as owned monitor but another thread could not lock it. > If you agree that the issue is preexisting I prefer handling that outside scope of this. I'm ok with that. A simple solution could then be making use of ThreadBlockInVM. When returning from EnterI in L413 we would set a rollback function in the HandshakeState which can be called in HandshakeState::suspend_in_handshake() to exit the OM. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 13:12:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 13:12:19 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:27:38 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/sweeper.cpp line 276: > >> 274: } >> 275: MutexUnlocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); >> 276: ThreadBlockInVM tbiv(JavaThread::current()); > > You already have the current thread. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 13:16:51 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 13:16:51 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 13:08:47 GMT, Richard Reingruber wrote: >> Today the ThreadBlockInVM tbivm(current); is inside scope of JavaThreadBlockedOnMonitorEnterState jtbmes(current, this);. >> So this can happen today also. >> >> If you are context switch just before current->set_current_pending_monitor(NULL);. >> Someone suspends you and look at those states. >> >> If you agree that the issue is preexisting I prefer handling that outside scope of this. > >> Today the ThreadBlockInVM tbivm(current); is inside scope of JavaThreadBlockedOnMonitorEnterState jtbmes(current, this);. >> So this can happen today also. >> >> If you are context switch just before current->set_current_pending_monitor(NULL);. >> Someone suspends you and look at those states. >> > > You mean the JVMTI agent suspends the current thread and then observes that the > thread state first has the attribute JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER and > in a later call it does not have it anymore (~ThreadBlockInVM doesn't check for > suspend)? Yes that's problematic too. > > With the new code we could remain suspended with > JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER. I think the OM would not be > reported as owned monitor but another thread could not lock it. > >> If you agree that the issue is preexisting I prefer handling that outside scope of this. > > I'm ok with that. > > A simple solution could then be making use of ThreadBlockInVM. When returning > from EnterI in L413 we would set a rollback function in the HandshakeState which > can be called in HandshakeState::suspend_in_handshake() to exit the OM. I'm mean the state you describe will be seen on that line: - The current thread is set as owner in ObjectMonitor::_owner - The thread state will still be JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER because of the JavaThreadBlockedOnMonitorEnterState in L389. - Thread::_current_pending_monitor has not been reset to NULL. Will be seen while we are context while in blocked state before clearing the _current_pending_monitor. Ok good. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From ysuenaga at openjdk.java.net Wed Apr 7 13:19:35 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 7 Apr 2021 13:19:35 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v3] In-Reply-To: References: <-Nst2cJnAG4QOBm6mOzLgpnbHIuUapDYuSjVl0jZZso=.40ec4b9e-0008-40cd-b9de-cdbe37a7000e@github.com> <0yqu_5IhRCJBjDLC4Nu3bg6i7yjADxS2Cu3C_IRaoF4=.5fa9d572-563d-44da-8261-78ee566b9d8a@github.com> Message-ID: On Wed, 7 Apr 2021 08:32:50 GMT, Andrew Haley wrote: > Maybe we should just concatenate all three files? Do you mean we should concatenate "compatible", "board_name", and "product_name"? It's impossible. We can see "compatible" file on the device which uses device tree, however we cannot see both "board_name" and "product_name" on it. Thus I prefer to attempt to read them sequentially. ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From rehn at openjdk.java.net Wed Apr 7 13:24:07 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 13:24:07 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: <8hNRJg0k8K1pqPObfAJGLkfSJVypvNeQfqSpBSRLvUE=.dadff50d-1895-4dca-a8cd-65eeae14126f@github.com> On Tue, 6 Apr 2021 18:37:38 GMT, Patricio Chilano Mateo 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.hpp line 122: > >> 120: // must take slow path, process_by_self(), if _lock is held. >> 121: bool should_process() { >> 122: return !_queue.is_empty() || _lock.is_locked(); > > While trying to think of the objectMonitor case I realize the order of this should probably be reversed with a load fence in between. Otherwise we could have the following scenario: > > Thread A blocks in ~ThreadInVMfromJava() -> wait_for_object_deoptimization() with _thread_blocked state. > Thread Z executes SuspendThreadHandshake on A. Gets context switched before adding the async handshake. > Thread A unblocks and transitions back to _thread_in_java. Calls SafepointMechanism::process_if_requested()-> process_if_requested_slow() since poll is armed. Checks that the handshake queue is empty. Gets context switched. > Thread Z installs async handshake in queue, releases _lock and continues. > Thread A checks _lock is unlocked so it doesn't call HandshakeState::process_by_self() to suspend and continues back to Java. (Poll will still be armed though because we will see it in update_poll_values()). You are correct. > src/hotspot/share/runtime/thread.hpp line 1142: > >> 1140: bool java_resume(); // higher-level resume logic called by the public APIs >> 1141: bool is_suspended() { return _handshake.is_suspended(); } >> 1142: bool suspend_request_pending() { return _handshake.suspend_request_pending(); } > > If you use is_suspended() to check for suspension in objectMonitor::enter() then we can remove this method. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 13:24:09 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 13:24:09 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: <8hNRJg0k8K1pqPObfAJGLkfSJVypvNeQfqSpBSRLvUE=.dadff50d-1895-4dca-a8cd-65eeae14126f@github.com> References: <8hNRJg0k8K1pqPObfAJGLkfSJVypvNeQfqSpBSRLvUE=.dadff50d-1895-4dca-a8cd-65eeae14126f@github.com> Message-ID: On Wed, 7 Apr 2021 13:17:40 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/handshake.hpp line 122: >> >>> 120: // must take slow path, process_by_self(), if _lock is held. >>> 121: bool should_process() { >>> 122: return !_queue.is_empty() || _lock.is_locked(); >> >> While trying to think of the objectMonitor case I realize the order of this should probably be reversed with a load fence in between. Otherwise we could have the following scenario: >> >> Thread A blocks in ~ThreadInVMfromJava() -> wait_for_object_deoptimization() with _thread_blocked state. >> Thread Z executes SuspendThreadHandshake on A. Gets context switched before adding the async handshake. >> Thread A unblocks and transitions back to _thread_in_java. Calls SafepointMechanism::process_if_requested()-> process_if_requested_slow() since poll is armed. Checks that the handshake queue is empty. Gets context switched. >> Thread Z installs async handshake in queue, releases _lock and continues. >> Thread A checks _lock is unlocked so it doesn't call HandshakeState::process_by_self() to suspend and continues back to Java. (Poll will still be armed though because we will see it in update_poll_values()). > > You are correct. Fixed, good catch! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 13:33:20 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 13:33:20 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:37:00 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/thread.cpp line 1442: > >> 1440: >> 1441: // The careful dance between thread suspension and exit is handled here: >> 1442: _handshake.thread_exit(); > > I don't like the fact this hides the set_terminating call. > > In fact I think I'd rather keep this in-line rather than tucking it away inside the handshake code. This looks too much like we're informing the handshake that the thread is exiting rather then coordinating thread termination with a late suspension request. The problem is that we need access to the private _lock to coordinate this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 13:42:52 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 13:42:52 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:41:20 GMT, David Holmes 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/thread.cpp line 2102: > >> 2100: do { >> 2101: set_thread_state(_thread_blocked); >> 2102: // Check if _external_suspend was set in the previous loop iteration. > > Note that the comment for this method at line 1806 needs updating as it refers to a now deleted method. I removed that line, not sure if the comment needs additional fixing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 13:42:55 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 13:42:55 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 09:37:37 GMT, Richard Reingruber wrote: >> src/hotspot/share/runtime/thread.cpp line 2105: >> >>> 2103: if (is_external_suspend()) { >>> 2104: java_suspend_self(); >>> 2105: } >> >> It is not at all clear to me how this method should interact with thread suspension ?? > > In JavaThread::wait_for_object_deoptimization() the current thread can transition to the safe state _thread_blocked. In that state it can be suspended. In the baseline version wait_for_object_deoptimization() checks for suspension explicitly and self suspends if positive. With this enhancement it happens implicitly by calling SafepointMechanism::process_if_requested(). Yes, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 13:43:00 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 13:43:00 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:46:00 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/thread.hpp line 1146: > >> 1144: // if external|deopt suspend is present. >> 1145: bool is_suspend_after_native() const { >> 1146: return (_suspend_flags & (_obj_deopt JFR_ONLY(| _trace_flag))) != 0; > > Comment at line 1144 needs updating. Fixed > src/hotspot/share/runtime/thread.inline.hpp line 194: > >> 192: >> 193: inline void JavaThread::set_exiting() { >> 194: // use release-store so the setting of _terminated is seen more quickly > > Pre-existing: A release doesn't push changes to main memory more quickly it only establishes ordering with previous loads and stores. Why do we need release semantics here - what state are with ordering with? What load-acquire are we pairing with? I beilive this is legacy from pre-ThreadsList era. Now we _should_ not have any such situations where such race matters. A thread on a ThreadsList can become terminated but it is still perfectly reachable. If we filter out terminated threads from a ThreadsList, any of those can become terminated just after any ways. So Atomic::store/load is fine here IMHO. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From hseigel at openjdk.java.net Wed Apr 7 13:58:35 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 7 Apr 2021 13:58:35 GMT Subject: RFR: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out In-Reply-To: References: Message-ID: <84Kuc9_kwcCmH2AodkB7HHQ2TXw9HQNAlBT1KxEJY-0=.4c913f54-c435-48f7-b44d-5615458438b0@github.com> On Wed, 7 Apr 2021 12:53:30 GMT, Coleen Phillimore wrote: > Added a flag so that thread 2 will notify thread 1 after it's waiting, and not before. > Ran 100x on macosx-x64-debug without timeout (actually ran original 100x without timeout also). > The test relies on one thread waiting at a place where another can find the class loading in progress. Alternate suggestions welcome. > Thanks! > Coleen Changes look good. One question: does 'ready' need to be volatile ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3375 From rehn at openjdk.java.net Wed Apr 7 14:03:12 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 14:03:12 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:50:17 GMT, David Holmes 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/thread.inline.hpp line 207: > >> 205: } >> 206: >> 207: inline void JavaThread::set_terminated(TerminatedTypes t) { > > I prefer set_terminated(arg) over the new set of methods. We had two methods: void set_terminated(TerminatedTypes t); void set_terminated_value(); Terminated is part of the name of the method, the name of the flag, the name of the type and part of the names of two of the states, which is very confusing. Also the setters now match the queries: E.g. `bool is_exiting()` The queries do not indicate in any sense that they are queries on the terminated flag. The state flag is an implementation detail from query POV. So to be consistent e.g. "set_exiting()" also hides the fact that we keep track of this with a flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 14:07:13 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 14:07:13 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <8H3OiD6YuG9DcS5H-teFeDXvNeMNneFTWzshRVckA_c=.e7fd792c-c20f-4a91-b4dd-e888a83e8d3e@github.com> On Wed, 31 Mar 2021 06:51:19 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/vmStructs.cpp line 764: > >> 762: \ >> 763: /*********************************/ \ >> 764: /* JavaThread (NOTE: incomplete) */ \ > > ??? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From lfoltan at openjdk.java.net Wed Apr 7 14:26:33 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 7 Apr 2021 14:26:33 GMT Subject: RFR: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out In-Reply-To: References: Message-ID: <2u-DidCqUuCQtHe8lkLzMHWOchm2Y2UByQDUFO7JkmM=.33095f14-9052-4a7e-ad9b-043cdcb87250@github.com> On Wed, 7 Apr 2021 12:53:30 GMT, Coleen Phillimore wrote: > Added a flag so that thread 2 will notify thread 1 after it's waiting, and not before. > Ran 100x on macosx-x64-debug without timeout (actually ran original 100x without timeout also). > The test relies on one thread waiting at a place where another can find the class loading in progress. Alternate suggestions welcome. > Thanks! > Coleen LGTM. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3375 From rehn at openjdk.java.net Wed Apr 7 14:28:17 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 14:28:17 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:53:50 GMT, David Holmes 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java line 79: > >> 77: } >> 78: >> 79: public boolean isExternalSuspend() { > > I assume a new SA API for thread suspension is needed here. If it is important to ask if a thread is suspended. The native stack-traces would easily show this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rrich at openjdk.java.net Wed Apr 7 14:36:41 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 7 Apr 2021 14:36:41 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 13:33:45 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/thread.cpp line 2102: >> >>> 2100: do { >>> 2101: set_thread_state(_thread_blocked); >>> 2102: // Check if _external_suspend was set in the previous loop iteration. >> >> Note that the comment for this method at line 1806 needs updating as it refers to a now deleted method. > > I removed that line, not sure if the comment needs additional fixing. I think David requested updating of the comment for `JavaThread::java_suspend_self_with_safepoint_check()`. I hope to delete the whole method soon and build on the new suspend mechanism, if Robbin is ok with that. For now I'd like to propose the following: // Wait for another thread to perform object reallocation and relocking on behalf of // this thread. // Raw thread state transition to _thread_blocked and back again to the original // state before returning are performed. The current thread is required to // change to _thread_blocked in order to be seen to be safepoint/handshake safe // whilst suspended and only after becoming handshake safe, the other thread can // complete the handshake used to synchronize with this thread and then perform // the reallocation and relocking. We cannot use the thread state transition // helpers because we arrive here in various states and also because the helpers // indirectly call this method. After leaving _thread_blocked we have to check // for safepoint/handshake, except if _thread_in_native. The thread is safe // without blocking then. Allowed states are enumerated in // SafepointSynchronize::block(). See also EscapeBarrier::sync_and_suspend_*() ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 14:36:43 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 14:36:43 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 06:57:16 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > test/hotspot/jtreg/serviceability/jvmti/SuspendWithCurrentThread/SuspendWithCurrentThread.java line 132: > >> 130: ThreadToSuspend.setAllThreadsReady(); >> 131: >> 132: while (!checkSuspendedStatus()) { > > The changes to this test are still quite unclear to me. Too hard to figure out what the test was originally trying to do! The test worked because we didn't check for suspend when leaving a safepoint request back to native. @pchilano have more info on why the test even works today. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 14:59:16 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 14:59:16 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 03:21:55 GMT, Patricio Chilano Mateo 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 three commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.hpp line 151: > >> 149: >> 150: bool is_suspended() { return Atomic::load(&_suspended); } >> 151: void set_suspend(bool to) { return Atomic::store(&_suspended, to); } > > Maybe set_suspended() instead()? Fixed > src/hotspot/share/runtime/objectMonitor.cpp line 436: > >> 434: current->set_current_pending_monitor(NULL); >> 435: >> 436: // We cleared the pending monitor info since we've just gotten past > > Comment below needs updating since it mentions ThreadBlockInVM but we are not using it anymore. Fixed > src/hotspot/share/runtime/thread.cpp line 277: > >> 275: #endif >> 276: >> 277: _SR_lock = new Monitor(Mutex::suspend_resume, "SR_lock", true, > > Mutex::suspend_resume rank is not used by any other monitor so we could remove it. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 15:04:41 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 15:04:41 GMT Subject: RFR: 8257831: Suspend with handshakes [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 14:31:05 GMT, Richard Reingruber wrote: >> I removed that line, not sure if the comment needs additional fixing. > > I think David requested updating of the comment for `JavaThread::java_suspend_self_with_safepoint_check()`. > > I hope to delete the whole method soon and build on the new suspend mechanism, if Robbin is ok with that. For now I'd like to propose the following: > > // Wait for another thread to perform object reallocation and relocking on behalf of > // this thread. > // Raw thread state transition to _thread_blocked and back again to the original > // state before returning are performed. The current thread is required to > // change to _thread_blocked in order to be seen to be safepoint/handshake safe > // whilst suspended and only after becoming handshake safe, the other thread can > // complete the handshake used to synchronize with this thread and then perform > // the reallocation and relocking. We cannot use the thread state transition > // helpers because we arrive here in various states and also because the helpers > // indirectly call this method. After leaving _thread_blocked we have to check > // for safepoint/handshake, except if _thread_in_native. The thread is safe > // without blocking then. Allowed states are enumerated in > // SafepointSynchronize::block(). See also EscapeBarrier::sync_and_suspend_*() Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From coleenp at openjdk.java.net Wed Apr 7 15:34:31 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Apr 2021 15:34:31 GMT Subject: RFR: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out [v2] In-Reply-To: References: Message-ID: > Added a flag so that thread 2 will notify thread 1 after it's waiting, and not before. > Ran 100x on macosx-x64-debug without timeout (actually ran original 100x without timeout also). > The test relies on one thread waiting at a place where another can find the class loading in progress. Alternate suggestions welcome. > Thanks! > Coleen Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add volatile ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3375/files - new: https://git.openjdk.java.net/jdk/pull/3375/files/d5991d9e..5958bdcb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3375&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3375&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3375.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3375/head:pull/3375 PR: https://git.openjdk.java.net/jdk/pull/3375 From coleenp at openjdk.java.net Wed Apr 7 15:34:31 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Apr 2021 15:34:31 GMT Subject: RFR: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out [v2] In-Reply-To: <84Kuc9_kwcCmH2AodkB7HHQ2TXw9HQNAlBT1KxEJY-0=.4c913f54-c435-48f7-b44d-5615458438b0@github.com> References: <84Kuc9_kwcCmH2AodkB7HHQ2TXw9HQNAlBT1KxEJY-0=.4c913f54-c435-48f7-b44d-5615458438b0@github.com> Message-ID: On Wed, 7 Apr 2021 13:55:40 GMT, Harold Seigel wrote: > Changes look good. One question: does 'ready' need to be volatile ? I added volatile to ready. Thanks Lois and Harold! ------------- PR: https://git.openjdk.java.net/jdk/pull/3375 From minqi at openjdk.java.net Wed Apr 7 15:37:49 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 7 Apr 2021 15:37:49 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v10] In-Reply-To: References: Message-ID: <8Em0aTz_KxKneptL7dOuu1ldmzYI0kwDzEfHkz1kQrc=.2ad4881c-23db-4934-8a79-f84db54a1417@github.com> > Hi, Please review > > Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with > `java -XX:DumpLoadedClassList= .... ` > to collect shareable class names and saved in file `` , then > `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` > With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. > The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. > New added jcmd option: > `jcmd VM.cds static_dump ` > or > `jcmd VM.cds dynamic_dump ` > To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. > The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Fix revert unintentionally comment, merge master. - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. - Remove redundant check for if a class is shareable - Fix according to review comment and add more tests - Fix filter more flags to exclude in static dump, add more test cases - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a756d8d7...b3d20348 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2737/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=09 Stats: 835 lines in 23 files changed: 762 ins; 58 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737 PR: https://git.openjdk.java.net/jdk/pull/2737 From dcubed at openjdk.java.net Wed Apr 7 15:48:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 7 Apr 2021 15:48:34 GMT Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 11:43:15 GMT, Robbin Ehn wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Address lyndseyBeil, robehn and sspitsyn CR comments. > > I really like simple agent code ?? > > Thanks! @robehn - Thanks for the re-review! And thank you for suggesting the much simpler agent code!! ------------- PR: https://git.openjdk.java.net/jdk/pull/2899 From pchilanomate at openjdk.java.net Wed Apr 7 15:52:45 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 7 Apr 2021 15:52:45 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 14:33:00 GMT, Robbin Ehn wrote: >> test/hotspot/jtreg/serviceability/jvmti/SuspendWithCurrentThread/SuspendWithCurrentThread.java line 132: >> >>> 130: ThreadToSuspend.setAllThreadsReady(); >>> 131: >>> 132: while (!checkSuspendedStatus()) { >> >> The changes to this test are still quite unclear to me. Too hard to figure out what the test was originally trying to do! > > The test worked because we didn't check for suspend when leaving a safepoint request back to native. > @pchilano have more info on why the test even works today. Right, the reason the test was working so far but not anymore without this changes is because before we didn't check for suspension on ~ThreadBlockInVM() after leaving a safepoint safe state. The interaction is kind of subtle: In the test the main thread creates 10 working threads and sets one of those to have the role of 'Suspender'. The 'Suspender' acquires agent_monitor(a jvmtirawmonitor), suspends all working threads including itself by calling jvmti->SuspendThreadList() and then it releases agent_monitor. In the mean time the main thread just blocks on agent_monitor until 'Suspender' releases it to check that everybody was indeed suspended. Now, at first glance this looks like(at least for me) the test should deadlock because 'Suspender' should never return from SuspendThreadList() to release agent_monitor since he was suspended too. The reason 'Suspender' returns from SuspendThreadList() is because he never actually checks for suspension after the safepoint operation (VM_ThreadsSuspendJVMTI) finished. 'Suspender' waits on the VMOperation_lock with as_suspend_equivalent=false (default) so it transitions back to _thread_in_vm without suspending. And then when going back to native in ~ThreadInVMfromNati ve() we also don't check for suspends (we now check it here too actually). The JVMTI specs says this about SuspendThreadList: "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." So this patch actually fixes that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 16:25:10 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 16:25:10 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 18:53:54 GMT, Serguei Spitsyn wrote: > Hi Robbin, > I'm looking at it. I have a concern that it can significantly impact Loom implementation. There is a non-trivial update in Loom to support virtual threads in JVMTI Suspend/Resume. So we need to make sure your approach is going to work for virtual threads as well. Hi Serguei, I looked at loom implementation. I will help you do the merge. The main thing seem to split some logic into the handshake itself. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 7 16:25:14 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 16:25:14 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <04Dot4HzYGzkxX3_VISq-flvgW76ptGorPrp2fOrDrA=.f76f8484-ac79-4e8e-b219-6f3a0bf6f1e0@github.com> On Wed, 31 Mar 2021 05:52:14 GMT, David Holmes 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 two commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.hpp line 139: > >> 137: Thread* active_handshaker() const { return _active_handshaker; } >> 138: >> 139: // Suspend/resume support > > This would be a good place to describe the operation of these two state fields Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From hseigel at openjdk.java.net Wed Apr 7 16:28:37 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 7 Apr 2021 16:28:37 GMT Subject: RFR: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 15:34:31 GMT, Coleen Phillimore wrote: >> Added a flag so that thread 2 will notify thread 1 after it's waiting, and not before. >> Ran 100x on macosx-x64-debug without timeout (actually ran original 100x without timeout also). >> The test relies on one thread waiting at a place where another can find the class loading in progress. Alternate suggestions welcome. >> Thanks! >> Coleen > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add volatile LGTM! ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3375 From rehn at openjdk.java.net Wed Apr 7 16:29:12 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 7 Apr 2021 16:29:12 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <8XHYnrIhSOcB6qEpq4-1FlTw8LvfPTmIG3LyIs3BC8E=.301d2dff-0341-44e3-b066-e80b3945a9a6@github.com> On Wed, 7 Apr 2021 16:23:08 GMT, Robbin Ehn wrote: >> Hi Robbin, >> I'm looking at it. I have a concern that it can significantly impact Loom implementation. There is a non-trivial update in Loom to support virtual threads in JVMTI Suspend/Resume. So we need to make sure your approach is going to work for virtual threads as well. > >> Hi Robbin, >> I'm looking at it. I have a concern that it can significantly impact Loom implementation. There is a non-trivial update in Loom to support virtual threads in JVMTI Suspend/Resume. So we need to make sure your approach is going to work for virtual threads as well. > > Hi Serguei, I looked at loom implementation. > I will help you do the merge. The main thing seem to split some logic into the handshake itself. > > Thanks Working on pushing a new version, it will not have addressed all comments but many of them. I will build and do testing before push, and start deep testing in the background. I also merge with mainline. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From aph at openjdk.java.net Wed Apr 7 17:06:34 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 7 Apr 2021 17:06:34 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v3] In-Reply-To: References: <-Nst2cJnAG4QOBm6mOzLgpnbHIuUapDYuSjVl0jZZso=.40ec4b9e-0008-40cd-b9de-cdbe37a7000e@github.com> <0yqu_5IhRCJBjDLC4Nu3bg6i7yjADxS2Cu3C_IRaoF4=.5fa9d572-563d-44da-8261-78ee566b9d8a@github.com> Message-ID: On Wed, 7 Apr 2021 13:16:13 GMT, Yasumasa Suenaga wrote: > > Maybe we should just concatenate all three files? > > Do you mean we should concatenate "compatible", "board_name", and "product_name"? It's impossible. Of course it isn't impossible. But if you really want to skip a file which is just "\n", then please check for the file being just "\n", not a file with "\n" as its first character. ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From phh at openjdk.java.net Wed Apr 7 17:51:56 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Wed, 7 Apr 2021 17:51:56 GMT Subject: RFR: 8264742: member variable _monitor of MonitorLocker is redundant In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 04:05:21 GMT, Xin Liu wrote: > MonitorLocker is a subclass of MutexLocker. The member variable _monitor > has the same value of _mutex in its base class. Marked as reviewed by phh (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3350 From xliu at openjdk.java.net Wed Apr 7 17:54:18 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 7 Apr 2021 17:54:18 GMT Subject: Integrated: 8264742: member variable _monitor of MonitorLocker is redundant In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 04:05:21 GMT, Xin Liu wrote: > MonitorLocker is a subclass of MutexLocker. The member variable _monitor > has the same value of _mutex in its base class. This pull request has now been integrated. Changeset: 774e5ae0 Author: Xin Liu Committer: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/774e5ae0 Stats: 15 lines in 1 file changed: 5 ins; 1 del; 9 mod 8264742: member variable _monitor of MonitorLocker is redundant Reviewed-by: coleenp, dholmes, phh ------------- PR: https://git.openjdk.java.net/jdk/pull/3350 From sspitsyn at openjdk.java.net Wed Apr 7 17:56:09 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 7 Apr 2021 17:56:09 GMT Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v4] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 19:46:38 GMT, Daniel D. Daugherty wrote: >> Add three tests from JDK-4413752 ported to JVM/TI: >> >> - RawMonitorEnter() with SuspendThread() >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/SuspendWithRawMonitorEnter.java >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp >> >> - ObjectMonitor enter() with SuspendThread() >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp >> >> - ObjectMonitor wait() with SuspendThread >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java >> - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp >> >> The Java files have a transaction diagram to show what each of the >> threads in the test is doing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Address lyndseyBeil, robehn and sspitsyn CR comments. Hi Dan, It looks good in general. But I think moving JVMTI error code checks to Java is a step in a wrong direction. First, it makes it inconsistent with all existing JVMTI tests. In this particular case, all the complexity is moved to Java side making it unbalanced. Also, we are working with Leonid toward creating relevant native testing lib for serviceability/jvmti tests (created it for Loom first) which has a support to print symbolic names (for error codes as well) if necessary. Not sure, I understood what wrong with the native check_jvmti_status(). It seems the id argument is not needed much and can be removed anyway. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2899 From dcubed at openjdk.java.net Wed Apr 7 19:20:40 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 7 Apr 2021 19:20:40 GMT Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 17:52:16 GMT, Serguei Spitsyn wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Address lyndseyBeil, robehn and sspitsyn CR comments. > > Hi Dan, > It looks good in general. > But I think moving JVMTI error code checks to Java is a step in a wrong direction. > First, it makes it inconsistent with all existing JVMTI tests. In this particular case, all the complexity is moved to Java side making it unbalanced. Also, we are working with Leonid toward creating relevant native testing lib for serviceability/jvmti tests (created it for Loom first) which has a support to print symbolic names (for error codes as well) if necessary. > Not sure, I understood what wrong with the native check_jvmti_status(). It seems the id argument is not needed much and can be removed anyway. > Thanks, > Serguei Hi @sspitsyn, I rather like the much simpler agent code and it puts the majority of logic in the .java file so the reader/reviewer doesn't have to jump back and forth between the two files nearly as much. The `id` argument had to be passed to the old version of the function calls in order for the logging messages generated by the agent code to (easily) have the same thread names as the Java side logging. Once all the error checking was moved to the Java side, that made the `id` argument no longer necessary and also allowed the native `check_jvmti_status()` function (along with other functions) to be removed. So there was nothing wrong with the native `check_jvmti_status()` function; it was just made obsolete by the code migration to the Java side. I consider @robehn's idea here to be good evolution for these kinds of tests to move code from the native side, where the code is more platform dependent, to the Java side, where the code is more platform independent. I hope I have convinced you that this is a good changeset for moving forward. ------------- PR: https://git.openjdk.java.net/jdk/pull/2899 From iklam at openjdk.java.net Wed Apr 7 19:46:44 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 7 Apr 2021 19:46:44 GMT Subject: RFR: 8214455: Relocate CDS archived regions to the top of the G1 heap [v3] In-Reply-To: References: Message-ID: > When the runtime heap and dump time heap have different sizes, it's possible that the archived heap regions are mapped to the middle of the runtime heap. Because the archived heap regions are pinned, this could reduce the size of the largest "humongous" array allocation. In the worst case, the maximum allocatable array length may be half of the optimal value. > > The fix is to relocate the archived regions to the top of the G1 heap (currently archived regions are supported only by G1 on 64-bit JVM). > > Note that usually the top of the G1 heap is placed just below the 32GB boundary. As a result, the archived heap regions are at the same location between run time and dump time, so no relocation is necessary. > > In mach5 testing, we occasionally run into this problem (see https://bugs.openjdk.java.net/browse/JDK-8239089), probably because we fail to reserve the heap below 32GB due to address space layout randomization (ASLR). 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' into 8214455-relocated-archived-regions-to-heap-top - fixed indentation (review comment by @calvinccheung) - @tschatzl review -- fix typos and whitespace - Added -Xlog:cds=debug in case this test fails again - 8214455: Relocate CDS archived regions to the top of the G1 heap ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3349/files - new: https://git.openjdk.java.net/jdk/pull/3349/files/bedd676d..43ee9680 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3349&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3349&range=01-02 Stats: 4956 lines in 137 files changed: 2977 ins; 1596 del; 383 mod Patch: https://git.openjdk.java.net/jdk/pull/3349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3349/head:pull/3349 PR: https://git.openjdk.java.net/jdk/pull/3349 From vlivanov at openjdk.java.net Wed Apr 7 21:03:14 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 7 Apr 2021 21:03:14 GMT Subject: RFR: 8264731: Introduce InstanceKlass::method_at_itable_or_null() [v3] In-Reply-To: References: Message-ID: > Introduce `InstanceKlass::method_at_itable_or_null()` - a non-throwing variant of `InstanceKlass::method_at_itable()` that implements interface method selection. > > As a cleanup, rewrite `InstanceKlass::method_at_itable()` on top of `InstanceKlass::method_at_itable_or_null()`. > > Testing: > * [x] hs-tier1 - hs-tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: itable_entry_found -> implements_interface renaming ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3344/files - new: https://git.openjdk.java.net/jdk/pull/3344/files/91b977c0..df179a08 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3344&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3344&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3344.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3344/head:pull/3344 PR: https://git.openjdk.java.net/jdk/pull/3344 From vlivanov at openjdk.java.net Wed Apr 7 21:03:15 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 7 Apr 2021 21:03:15 GMT Subject: RFR: 8264731: Introduce InstanceKlass::method_at_itable_or_null() [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 05:26:01 GMT, David Holmes wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanups > > Update looks good - thanks - but I'd like to see it extend a little further. > > Thanks, > David Thanks for the reviews, Coleen and David. > src/hotspot/share/oops/instanceKlass.cpp line 3180: > >> 3178: } >> 3179: >> 3180: Method* InstanceKlass::method_at_itable_or_null(InstanceKlass* holder, int index, bool& itable_entry_found) { > > The change to use implements_interface applies in here too. Thanks. Sure, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3344 From vlivanov at openjdk.java.net Wed Apr 7 21:12:13 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 7 Apr 2021 21:12:13 GMT Subject: Integrated: 8264731: Introduce InstanceKlass::method_at_itable_or_null() In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 17:40:58 GMT, Vladimir Ivanov wrote: > Introduce `InstanceKlass::method_at_itable_or_null()` - a non-throwing variant of `InstanceKlass::method_at_itable()` that implements interface method selection. > > As a cleanup, rewrite `InstanceKlass::method_at_itable()` on top of `InstanceKlass::method_at_itable_or_null()`. > > Testing: > * [x] hs-tier1 - hs-tier6 This pull request has now been integrated. Changeset: 6e2b82a4 Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk/commit/6e2b82a4 Stats: 48 lines in 3 files changed: 16 ins; 9 del; 23 mod 8264731: Introduce InstanceKlass::method_at_itable_or_null() Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3344 From vlivanov at openjdk.java.net Wed Apr 7 21:41:58 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 7 Apr 2021 21:41:58 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v3] In-Reply-To: References: Message-ID: > Turn `resolved_method` parameter into raw `Method*`. > > Testing: > * [x] hs-tier1 - hs-tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Move itable_index_of_interface_method() implementation to InstanceKlass ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3346/files - new: https://git.openjdk.java.net/jdk/pull/3346/files/a2bf4794..9dfc9437 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3346&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3346&range=01-02 Stats: 55 lines in 5 files changed: 28 ins; 21 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3346/head:pull/3346 PR: https://git.openjdk.java.net/jdk/pull/3346 From vlivanov at openjdk.java.net Wed Apr 7 21:43:48 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 7 Apr 2021 21:43:48 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v4] In-Reply-To: References: Message-ID: > Turn `resolved_method` parameter into raw `Method*`. > > Testing: > * [x] hs-tier1 - hs-tier6 Vladimir Ivanov 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 branch 'master' into 8264732.vtable_index_of_interface_method - Move itable_index_of_interface_method() implementation to InstanceKlass - Revert jvmciCompilerToVM.cpp change. - LinkResolver::vtable_index_of_interface_method ------------- Changes: https://git.openjdk.java.net/jdk/pull/3346/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3346&range=03 Stats: 55 lines in 3 files changed: 29 ins; 23 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3346/head:pull/3346 PR: https://git.openjdk.java.net/jdk/pull/3346 From vlivanov at openjdk.java.net Wed Apr 7 21:47:59 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 7 Apr 2021 21:47:59 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 05:32:46 GMT, David Holmes wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert jvmciCompilerToVM.cpp change. > > Seems quite reasonable - though unsure of the motivation. > > Do we need a NoSafepointVerifier in LinkResolver::vtable_index_of_interface_method to ensure the raw Method* remains valid? > > Thanks, > David Thinking more about it, `methodHandle` does look more natural than a raw `Method*` on `LinkResolver`. What do you think about leaving `LinkResolver` as it is now and move `vtable_index_of_interface_method` implementation to `InstanceKlass` instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/3346 From sspitsyn at openjdk.java.net Wed Apr 7 22:48:14 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 7 Apr 2021 22:48:14 GMT Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 19:17:33 GMT, Daniel D. Daugherty wrote: >> Hi Dan, >> It looks good in general. >> But I think moving JVMTI error code checks to Java is a step in a wrong direction. >> First, it makes it inconsistent with all existing JVMTI tests. In this particular case, all the complexity is moved to Java side making it unbalanced. Also, we are working with Leonid toward creating relevant native testing lib for serviceability/jvmti tests (created it for Loom first) which has a support to print symbolic names (for error codes as well) if necessary. >> Not sure, I understood what wrong with the native check_jvmti_status(). It seems the id argument is not needed much and can be removed anyway. >> Thanks, >> Serguei > > Hi @sspitsyn, > > I rather like the much simpler agent code and it puts the majority of logic > in the .java file so the reader/reviewer doesn't have to jump back and forth > between the two files nearly as much. > > The `id` argument had to be passed to the old version of the function calls > in order for the logging messages generated by the agent code to (easily) > have the same thread names as the Java side logging. Once all the error > checking was moved to the Java side, that made the `id` argument no longer > necessary and also allowed the native `check_jvmti_status()` function (along > with other functions) to be removed. So there was nothing wrong with the > native `check_jvmti_status()` function; it was just made obsolete by the code > migration to the Java side. > > I consider @robehn's idea here to be good evolution for these kinds of tests to > move code from the native side, where the code is more platform dependent, > to the Java side, where the code is more platform independent. > > I hope I have convinced you that this is a good changeset for moving forward. Dan, I'm sorry, I do not see much value in this approach going forward. One line with a call to check_jvmti_status() does not add much to the platform dependency no to complexity in native code. Also, more sophisticated analysis of the returned error code frequently is needed. Also, I consider it not feasible to move a thousand of JVMTI tests in this direction. So that we will end up with inconsistency over all tests. I've already marked this as reviewed, so you can push it. But I'm against following this pattern going forward. Or at least, we need to consult with the SQE engineers first. Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/2899 From coleenp at openjdk.java.net Wed Apr 7 23:04:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Apr 2021 23:04:06 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 21:41:58 GMT, Vladimir Ivanov wrote: >> Turn `resolved_method` parameter into raw `Method*`. >> >> Testing: >> * [x] hs-tier1 - hs-tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Move itable_index_of_interface_method() implementation to InstanceKlass src/hotspot/share/oops/instanceKlass.cpp line 3199: > 3197: // First check in default method array > 3198: if (!intf_method->is_abstract() && this->default_methods() != NULL) { > 3199: int index = InstanceKlass::find_method_index(this->default_methods(), Yes, please, this looks a lot better! Then linkResolver can deal with methodHandle consistently so it doesn't go away with redefinition, and this function is nice here with the other like functions. It doesn't need InstanceKlass:: before find_method_index, or the this->'s. ------------- PR: https://git.openjdk.java.net/jdk/pull/3346 From iklam at openjdk.java.net Thu Apr 8 00:44:14 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 8 Apr 2021 00:44:14 GMT Subject: RFR: 8214455: Relocate CDS archived regions to the top of the G1 heap [v3] In-Reply-To: References: Message-ID: <7FUdIE0NHT29sCEmGSXe0FYD_99Xq0HpO6JP5uLoJpA=.68ec144f-4d34-48c0-a6d2-89760d2e7617@github.com> On Tue, 6 Apr 2021 09:41:25 GMT, Thomas Schatzl 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 five additional commits since the last revision: >> >> - Merge branch 'master' into 8214455-relocated-archived-regions-to-heap-top >> - fixed indentation (review comment by @calvinccheung) >> - @tschatzl review -- fix typos and whitespace >> - Added -Xlog:cds=debug in case this test fails again >> - 8214455: Relocate CDS archived regions to the top of the G1 heap > > Lgtm. Thanks @tschatzl and @calvinccheung for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3349 From iklam at openjdk.java.net Thu Apr 8 00:49:20 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 8 Apr 2021 00:49:20 GMT Subject: Integrated: 8214455: Relocate CDS archived regions to the top of the G1 heap In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 21:48:43 GMT, Ioi Lam wrote: > When the runtime heap and dump time heap have different sizes, it's possible that the archived heap regions are mapped to the middle of the runtime heap. Because the archived heap regions are pinned, this could reduce the size of the largest "humongous" array allocation. In the worst case, the maximum allocatable array length may be half of the optimal value. > > The fix is to relocate the archived regions to the top of the G1 heap (currently archived regions are supported only by G1 on 64-bit JVM). > > Note that usually the top of the G1 heap is placed just below the 32GB boundary. As a result, the archived heap regions are at the same location between run time and dump time, so no relocation is necessary. > > In mach5 testing, we occasionally run into this problem (see https://bugs.openjdk.java.net/browse/JDK-8239089), probably because we fail to reserve the heap below 32GB due to address space layout randomization (ASLR). This pull request has now been integrated. Changeset: 78d1164c Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/78d1164c Stats: 147 lines in 8 files changed: 139 ins; 0 del; 8 mod 8214455: Relocate CDS archived regions to the top of the G1 heap Reviewed-by: tschatzl, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/3349 From dcubed at openjdk.java.net Thu Apr 8 01:30:17 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 8 Apr 2021 01:30:17 GMT Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 22:44:41 GMT, Serguei Spitsyn wrote: >> Hi @sspitsyn, >> >> I rather like the much simpler agent code and it puts the majority of logic >> in the .java file so the reader/reviewer doesn't have to jump back and forth >> between the two files nearly as much. >> >> The `id` argument had to be passed to the old version of the function calls >> in order for the logging messages generated by the agent code to (easily) >> have the same thread names as the Java side logging. Once all the error >> checking was moved to the Java side, that made the `id` argument no longer >> necessary and also allowed the native `check_jvmti_status()` function (along >> with other functions) to be removed. So there was nothing wrong with the >> native `check_jvmti_status()` function; it was just made obsolete by the code >> migration to the Java side. >> >> I consider @robehn's idea here to be good evolution for these kinds of tests to >> move code from the native side, where the code is more platform dependent, >> to the Java side, where the code is more platform independent. >> >> I hope I have convinced you that this is a good changeset for moving forward. > > Dan, > I'm sorry, I do not see much value in this approach going forward. One line with a call to check_jvmti_status() does not add much to the platform dependency no to complexity in native code. Also, more sophisticated analysis of the returned error code frequently is needed. Also, I consider it not feasible to move a thousand of JVMTI tests in this direction. So that we will end up with inconsistency over all tests. > I've already marked this as reviewed, so you can push it. But I'm against following this pattern going forward. Or at least, we need to consult with the SQE engineers first. > Thanks, > Serguei @sspitsyn - First, thanks for approving the changes! Second, I'm _not_ proposing changing any other JVM/TI tests to use this style. The only reason that this style works (for me and @robehn) is because none of these JVM/TI calls is expected to fail. The tests are carefully constructed to exercise the code for a race condition that will result in a hang or a crash (if something goes wrong). In the case of these tests, we don't need sophisticated analysis of the returned error codes. Again, thanks for approving these tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/2899 From ysuenaga at openjdk.java.net Thu Apr 8 02:03:15 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 8 Apr 2021 02:03:15 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v4] In-Reply-To: References: Message-ID: > `jdk.CPUInformation` event on AArch64 has valid CPU description in [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491), however it does not work on UEFI booted machine. > > [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491) refers device tree to get board name, however it does not exist on UEFI. We need to refer DMI. > However we need to have root privilege, so we refer /sys/devices/virtual/dmi/id to avoid it. > > We can get board name from /sys/devices/virtual/dmi/id/board_name, but some machine set empty string to it. So we will refer /sys/devices/virtual/dmi/id/product_name as a fallback. > > For example, we can get following CPU description on AWS A1 instance after this change: > > jdk.CPUInformation { > startTime = 05:28:24.506 > cpu = "AArch64" > description = "AArch64 a1.2xlarge 0x41:0x0:0xd08:3, simd, crc, aes, sha1, sha256" > sockets = 8 > cores = 8 > hwThreads = 8 > } Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: check the contents whether it is just "\n" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3259/files - new: https://git.openjdk.java.net/jdk/pull/3259/files/e5b75dc5..a1b94754 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3259&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3259&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3259.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3259/head:pull/3259 PR: https://git.openjdk.java.net/jdk/pull/3259 From ysuenaga at openjdk.java.net Thu Apr 8 02:03:15 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 8 Apr 2021 02:03:15 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v4] In-Reply-To: References: <-Nst2cJnAG4QOBm6mOzLgpnbHIuUapDYuSjVl0jZZso=.40ec4b9e-0008-40cd-b9de-cdbe37a7000e@github.com> <0yqu_5IhRCJBjDLC4Nu3bg6i7yjADxS2Cu3C_IRaoF4=.5fa9d572-563d-44da-8261-78ee566b9d8a@github.com> Message-ID: On Wed, 7 Apr 2021 17:02:55 GMT, Andrew Haley wrote: >>> Maybe we should just concatenate all three files? >> >> Do you mean we should concatenate "compatible", "board_name", and "product_name"? It's impossible. We can see "compatible" file on the device which uses device tree, however we cannot see both "board_name" and "product_name" on it. Thus I prefer to attempt to read them sequentially. > >> > Maybe we should just concatenate all three files? >> >> Do you mean we should concatenate "compatible", "board_name", and "product_name"? It's impossible. > > Of course it isn't impossible. But if you really want to skip a file which is just "\n", then please check for the file being just "\n", not a file with "\n" as its first character. I pushed new commit to check the contents whether it is just "\n". Could you review again? ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From whuang at openjdk.java.net Thu Apr 8 03:33:46 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 8 Apr 2021 03:33:46 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error Message-ID: As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. The other whole bigger big will be fixed in the other issue. ------------- Commit messages: - 8264760: JVM crashes when two threads encounter the same resolution error Changes: https://git.openjdk.java.net/jdk/pull/3392/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264760 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3392.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3392/head:pull/3392 PR: https://git.openjdk.java.net/jdk/pull/3392 From yyang at openjdk.java.net Thu Apr 8 03:44:38 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 8 Apr 2021 03:44:38 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling Message-ID: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> MemProfiler is a very old development option added at: ^As 00018/00000/00000 ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 ^Ac date and time created 98/04/14 13:18:32 by renes ^Ae Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. Thanks! Yang ------------- Commit messages: - remove memprofile Changes: https://git.openjdk.java.net/jdk/pull/3393/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3393&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264881 Stats: 201 lines in 8 files changed: 0 ins; 201 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3393.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3393/head:pull/3393 PR: https://git.openjdk.java.net/jdk/pull/3393 From yyang at openjdk.java.net Thu Apr 8 03:51:06 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 8 Apr 2021 03:51:06 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: <0G5GvIyCJeDfetSLreWC9vOueJgQ3resRkRFvS8c64I=.71b09c36-4fd4-4dad-9cf4-e7366ad02431@github.com> On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > MemProfiler is a very old development option added at: > > ^As 00018/00000/00000 > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > ^Ac date and time created 98/04/14 13:18:32 by renes > ^Ae > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. > > Thanks! > Yang Gentle query: I do find another three product options(UseNewCode\d) that do nothing, they have been added in JDK6 as initial load commit(Maybe early). Does anyone know what's the intention of adding these options? Is it reasonable to remove them now? ------------- PR: https://git.openjdk.java.net/jdk/pull/3393 From whuang at openjdk.java.net Thu Apr 8 04:07:48 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 8 Apr 2021 04:07:48 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v2] In-Reply-To: References: Message-ID: > As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. The other whole bigger big will be fixed in the other issue. Wang Huang has updated the pull request incrementally with one additional commit since the last revision: add test cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3392/files - new: https://git.openjdk.java.net/jdk/pull/3392/files/4774b25f..7d7c7442 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=00-01 Stats: 196 lines in 2 files changed: 196 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3392.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3392/head:pull/3392 PR: https://git.openjdk.java.net/jdk/pull/3392 From whuang at openjdk.java.net Thu Apr 8 04:38:37 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 8 Apr 2021 04:38:37 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: References: Message-ID: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> > As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. The other whole bigger big will be fixed in the other issue. Wang Huang has updated the pull request incrementally with one additional commit since the last revision: add throw exception ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3392/files - new: https://git.openjdk.java.net/jdk/pull/3392/files/7d7c7442..b11b658a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=01-02 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3392.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3392/head:pull/3392 PR: https://git.openjdk.java.net/jdk/pull/3392 From dholmes at openjdk.java.net Thu Apr 8 05:19:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 05:19:05 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Thu, 8 Apr 2021 04:38:37 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. The other whole bigger big will be fixed in the other issue. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > add throw exception Hi Wang, Thanks for reporting this and offering to fix it. I have a comment on the actual fix and a few issues with the testcase - though thanks for adding one. With a race condition like this it is hard to write a test that will fail reliably without the fix. Thanks, David src/hotspot/share/classfile/systemDictionary.cpp line 1939: > 1937: ResolutionErrorEntry* entry = resolution_errors()->find_entry(index, hash, pool, which); > 1938: if (entry != NULL && entry->nest_host_error() == NULL) { > 1939: entry->set_nest_host_error(message); You should never find an entry where the nest_host_error() is NULL. If there were such an entry then it implies a regular resolution error occurred, but that means we cannot have reached this code as `klass_at` in our caller would have thrown the exception. So this should simply be: if (entry != NULL) { assert(entry->nest_host_error() != NULL, "cannot have a NULL error at this point"); } You also need to delete part of the method comment: //... If an entry already exists it will // be updated with the nest host error message. as we don't do that. test/hotspot/jtreg/runtime/Nestmates/membership/HostNoNestMember.jcod line 1: > 1: class HostNoNestMember { This new file needs a copyright notice and GPL header. Also please add a comment stating what this jcod file describes - see other jcod files in the directory for example. test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 38: > 36: import java.util.concurrent.CountDownLatch; > 37: > 38: class HostNoNestMember { Please add a comment describing how this class is replaced with the jcode version, and the difference in that version. test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 43: > 41: } > 42: > 43: public int foo() { Please call this "test". test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 53: > 51: public static void main(String args[]) throws Throwable { > 52: TestNestHostErrorWithMultiThread t = new TestNestHostErrorWithMultiThread(); > 53: t.test(); There is no need to create an instance - just use a static test method. The test code could be placed directly in main in this case. test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 58: > 56: public void test() throws Throwable { > 57: > 58: CountDownLatch latch = new CountDownLatch(1); The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives. test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 62: > 60: new Thread(() -> { > 61: try { > 62: latch.await(); Please add a comment: // Try to have all threads trigger the nesthost check at the same time test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 64: > 62: latch.await(); > 63: HostNoNestMember h = new HostNoNestMember(); > 64: h.foo(); Please follow this by: `throw new RuntimeException("Did not get expected IllegalAccessError");` test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 68: > 66: System.out.println("OK - got expected exception: " + expected); > 67: } catch (InterruptedException e) {} > 68: }).start(); Please extract the logic to a Runnable so that both threads can use that one runnable rather than duplicating the code. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3392 From dholmes at openjdk.java.net Thu Apr 8 05:29:10 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 05:29:10 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Thu, 8 Apr 2021 04:38:37 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. The other whole bigger big will be fixed in the other issue. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > add throw exception test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 51: > 49: public class TestNestHostErrorWithMultiThread { > 50: > 51: public static void main(String args[]) throws Throwable { "throws Throwable" is only necessary if you want unlisted checked exceptions to propagate. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From david.holmes at oracle.com Thu Apr 8 05:34:49 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Apr 2021 15:34:49 +1000 Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: <0G5GvIyCJeDfetSLreWC9vOueJgQ3resRkRFvS8c64I=.71b09c36-4fd4-4dad-9cf4-e7366ad02431@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> <0G5GvIyCJeDfetSLreWC9vOueJgQ3resRkRFvS8c64I=.71b09c36-4fd4-4dad-9cf4-e7366ad02431@github.com> Message-ID: <2a85f724-0d53-c96b-860e-2993fcd10534@oracle.com> On 8/04/2021 1:51 pm, Yi Yang wrote: > On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > >> MemProfiler is a very old development option added at: >> >> ^As 00018/00000/00000 >> ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 >> ^Ac date and time created 98/04/14 13:18:32 by renes >> ^Ae >> >> Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. >> >> After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. >> >> Thanks! >> Yang > > Gentle query: I do find another three product options(UseNewCode\d) that do nothing, they have been added in JDK6 as initial load commit(Maybe early). Does anyone know what's the intention of adding these options? Is it reasonable to remove them now? The UseNewCode flags are there as a development aid so that you can conditionally enable changed logic during development without needing to add a new runtime flag just for that. It can be very useful for gating changes when doing performance runs. No code ever gets committed that actually uses them though. So no, please do not delete them. :) Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3393 > From dholmes at openjdk.java.net Thu Apr 8 05:44:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 05:44:05 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > MemProfiler is a very old development option added at: > > ^As 00018/00000/00000 > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > ^Ac date and time created 98/04/14 13:18:32 by renes > ^Ae > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. > > Thanks! > Yang Hi Yi, Actual code removal looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3393 From sspitsyn at openjdk.java.net Thu Apr 8 05:57:21 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 8 Apr 2021 05:57:21 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 15:48:55 GMT, Patricio Chilano Mateo wrote: >> The test worked because we didn't check for suspend when leaving a safepoint request back to native. >> @pchilano have more info on why the test even works today. > > Right, the reason the test was working so far but not anymore without this changes is because before we didn't check for suspension on ~ThreadBlockInVM() after leaving a safepoint safe state. The interaction is kind of subtle: > In the test the main thread creates 10 working threads and sets one of those to have the role of 'Suspender'. The 'Suspender' acquires agent_monitor(a jvmtirawmonitor), suspends all working threads including itself by calling jvmti->SuspendThreadList() and then it releases agent_monitor. In the mean time the main thread just blocks on agent_monitor until 'Suspender' releases it to check that everybody was indeed suspended. Now, at first glance this looks like(at least for me) the test should deadlock because 'Suspender' should never return from SuspendThreadList() to release agent_monitor since he was suspended too. The reason 'Suspender' returns from SuspendThreadList() is because he never actually checks for suspension after the safepoint operation (VM_ThreadsSuspendJVMTI) finished. 'Suspender' waits on the VMOperation_lock with as_suspend_equivalent=false (default) so it transitions back to _thread_in_vm without suspending. And then when going back to native in ~ThreadInVMfromNa tive() we also don't check for suspends (we now check it here too actually). > The JVMTI specs says this about SuspendThreadList: > > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > So this patch actually fixes that. We also had to fix deadlock in this test in Loom. The fix is almost the same, and I agree with it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From yyang at openjdk.java.net Thu Apr 8 06:04:44 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 8 Apr 2021 06:04:44 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 05:38:56 GMT, David Holmes wrote: >> MemProfiler is a very old development option added at: >> >> ^As 00018/00000/00000 >> ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 >> ^Ac date and time created 98/04/14 13:18:32 by renes >> ^Ae >> >> Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. >> >> After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. >> >> Thanks! >> Yang > > Hi Yi, > > Actual code removal looks good. > > Thanks, > David > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ > > On 8/04/2021 1:51 pm, Yi Yang wrote: > > > On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > > > MemProfiler is a very old development option added at: > > > ^As 00018/00000/00000 > > > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > > > ^Ac date and time created 98/04/14 13:18:32 by renes > > > ^Ae > > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > > After a short discussion in https://github.com/[/pull/3340](https://github.com/openjdk/jdk/pull/3340), I'd like to propose removing the memprofiler if there are no strong objections. > > > Thanks! > > > Yang > > > > > > Gentle query: I do find another three product options(UseNewCode\d) that do nothing, they have been added in JDK6 as initial load commit(Maybe early). Does anyone know what's the intention of adding these options? Is it reasonable to remove them now? > > The UseNewCode flags are there as a development aid so that you can > conditionally enable changed logic during development without needing to > add a new runtime flag just for that. It can be very useful for gating > changes when doing performance runs. No code ever gets committed that > actually uses them though. > > So no, please do not delete them. :) > > Thanks, > David Got it. Thank you David, you are the OpenJDK encyclopedia. :) (PS: it looks like they are wrongly marked as product flags) ------------- PR: https://git.openjdk.java.net/jdk/pull/3393 From dholmes at openjdk.java.net Thu Apr 8 06:08:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 06:08:11 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines In-Reply-To: <4PYKSVkgr739q_k1jvxWUq2CHwF5OjL6poP-7m63Kqs=.1537ccc1-976c-4b3e-8508-8ac98d9c134d@github.com> References: <4PYKSVkgr739q_k1jvxWUq2CHwF5OjL6poP-7m63Kqs=.1537ccc1-976c-4b3e-8508-8ac98d9c134d@github.com> Message-ID: On Fri, 19 Mar 2021 11:56:43 GMT, Coleen Phillimore wrote: >> Changes requested by coleenp (Reviewer). > > I thought the purpose of this work was to make TRAPS and the JRT/JVM_ENTRY macros take JavaThread instead of Thread. > ie #define TRAPS JavaThread* THREAD I'm closing this PR and coming back with a new version that we have discussed offline. A clean start will be easier. ------------- PR: https://git.openjdk.java.net/jdk/pull/3062 From dholmes at openjdk.java.net Thu Apr 8 06:08:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 06:08:12 GMT Subject: Withdrawn: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 02:48:05 GMT, David Holmes wrote: > All JRT_ENTRY routines are required to have a parameter, "JavaThread* thread", which must be the current thread. The JRT_ENTRY, and related macros, then use this parameter and also expose it as THREAD for use with exception macros. But the fact "thread" is the current thread is lost in some routines and we see strange calls to other code that pass both "thread" and "THREAD" as distinct parameters - primarily when a TRAPS method is involved. > > This should be cleaned up along with a general check on misuse of TRAPS/THREAD. > > Testing: tiers 1-3 > > Thanks, > David This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3062 From sspitsyn at openjdk.java.net Thu Apr 8 06:08:45 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 8 Apr 2021 06:08:45 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: <8XHYnrIhSOcB6qEpq4-1FlTw8LvfPTmIG3LyIs3BC8E=.301d2dff-0341-44e3-b066-e80b3945a9a6@github.com> References: <8XHYnrIhSOcB6qEpq4-1FlTw8LvfPTmIG3LyIs3BC8E=.301d2dff-0341-44e3-b066-e80b3945a9a6@github.com> Message-ID: On Wed, 7 Apr 2021 16:25:28 GMT, Robbin Ehn wrote: >>> Hi Robbin, >>> I'm looking at it. I have a concern that it can significantly impact Loom implementation. There is a non-trivial update in Loom to support virtual threads in JVMTI Suspend/Resume. So we need to make sure your approach is going to work for virtual threads as well. >> >> Hi Serguei, I looked at loom implementation. >> I will help you do the merge. The main thing seem to split some logic into the handshake itself. >> >> Thanks > > Working on pushing a new version, it will not have addressed all comments but many of them. > I will build and do testing before push, and start deep testing in the background. > > I also merge with mainline. Hi Robbin, Thank you for the reply and suggestion to help with merge. I made the first pass through the webrev. The fix looks pretty good in general - nice simplifications! My estimation is that it should not be a big problem to merge it with Loom while it can require some effort to do so. I'm going for another pass to look on details. Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From xxinliu at amazon.com Thu Apr 8 06:56:09 2021 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 8 Apr 2021 06:56:09 +0000 Subject: Appropriate way to delete NonJavaThread objects? Message-ID: Hi, Hotspot developers, I have a question about NonJavaThread destructor. Currently, there are some NonJavaThread subclasses. Here is a simple class hierarchy. Thread NonJavaThrea NamedThread WorkerThread VMThread WatcherThread JfrThreadSampler I found some subclasses of NonJavaThread disallow destruction. Eg. VMThread and WatcherThread simply abort. // No destruction allowed ~VMThread() { guarantee(false, "VMThread deletion must fix the race with VM termination"); } Is it absolutely no resource leak if we skip ~Thread()? I know Linux/FreeBSD guarantee to reclaim anything when a process is terminated, but is it true for other platforms? Putting aside resource leak, I don't think all NonJavaThread subclasses necessarily have same lifecycle of JVM. Current NonJavaThread implementation seems to inhibit from complete destruction. eg. JfrThreadSampler uses the following approach to delete itself. void JfrThreadSampler::post_run() { this->NonJavaThread::post_run(); delete this; } I think this code is correct, but it is fragile because NonJavaThread::post_run() nullifies Thread::clear_thread_current() before Thread::~Thread(). "delete this" will hit the assertion of Thread::current() at this statement. // osthread() can be NULL, if creation of thread failed. if (osthread() != NULL) os::free_thread(osthread()) Does it matter if we ignore all destructions of NonJavaThread objects? If the answer is no, is there an appropriate way to delete them? Thanks, --lx From rehn at openjdk.java.net Thu Apr 8 07:17:48 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 8 Apr 2021 07:17:48 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: Message-ID: > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - White space fixes - Merge branch 'master' into SuspendInHandshake - Review fixes - Merge branch 'master' into SuspendInHandshake - Merge branch 'master' into SuspendInHandshake - 8257831: Suspend with handshake (review baseline) ------------- Changes: https://git.openjdk.java.net/jdk/pull/3191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=03 Stats: 1341 lines in 39 files changed: 281 ins; 865 del; 195 mod Patch: https://git.openjdk.java.net/jdk/pull/3191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191 PR: https://git.openjdk.java.net/jdk/pull/3191 From dholmes at openjdk.java.net Thu Apr 8 07:42:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 07:42:24 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines Message-ID: The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). Some missing CHECK_ uses were added. Testing: - tiers 1-3 Thanks, David ------------- Commit messages: - 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines Changes: https://git.openjdk.java.net/jdk/pull/3394/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3394&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263709 Stats: 876 lines in 21 files changed: 15 ins; 27 del; 834 mod Patch: https://git.openjdk.java.net/jdk/pull/3394.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3394/head:pull/3394 PR: https://git.openjdk.java.net/jdk/pull/3394 From sspitsyn at openjdk.java.net Thu Apr 8 08:15:33 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 8 Apr 2021 08:15:33 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: <8XHYnrIhSOcB6qEpq4-1FlTw8LvfPTmIG3LyIs3BC8E=.301d2dff-0341-44e3-b066-e80b3945a9a6@github.com> Message-ID: On Thu, 8 Apr 2021 06:02:35 GMT, Serguei Spitsyn wrote: >> Working on pushing a new version, it will not have addressed all comments but many of them. >> I will build and do testing before push, and start deep testing in the background. >> >> I also merge with mainline. > > Hi Robbin, > Thank you for the reply and suggestion to help with merge. I made the first pass through the webrev. The fix looks pretty good in general - nice simplifications! My estimation is that it should not be a big problem to merge it with Loom while it can require some effort to do so. I'm going for another pass to look on details. > Thanks, > Serguei The functions JvmtiSuspendControl::suspend and JvmtiSuspendControl::resume are not really needed anymore. You probably decided to keep them around to simplify merges a little bit. Is that right? ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From sspitsyn at openjdk.java.net Thu Apr 8 08:27:22 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 8 Apr 2021 08:27:22 GMT Subject: RFR: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI [v4] In-Reply-To: References: Message-ID: <-MO0WplIfGU2pEZifqv0Ow9Og7Gj-u2A8AqzYe_Bx8k=.e577f9ea-904f-4098-ac62-1a2a4f2218a4@github.com> On Thu, 8 Apr 2021 01:25:25 GMT, Daniel D. Daugherty wrote: >> Dan, >> I'm sorry, I do not see much value in this approach going forward. One line with a call to check_jvmti_status() does not add much to the platform dependency no to complexity in native code. Also, more sophisticated analysis of the returned error code frequently is needed. Also, I consider it not feasible to move a thousand of JVMTI tests in this direction. So that we will end up with inconsistency over all tests. >> I've already marked this as reviewed, so you can push it. But I'm against following this pattern going forward. Or at least, we need to consult with the SQE engineers first. >> Thanks, >> Serguei > > @sspitsyn - First, thanks for approving the changes! > > Second, I'm _not_ proposing changing any other JVM/TI tests to use this style. The only > reason that this style works (for me and @robehn) is because none of these JVM/TI calls > is expected to fail. The tests are carefully constructed to exercise the code for a race > condition that will result in a hang or a crash (if something goes wrong). In the case of > these tests, we don't need sophisticated analysis of the returned error codes. > > Again, thanks for approving these tests. Dan, thank you for extra explanation and for taking care to port these old tests! ------------- PR: https://git.openjdk.java.net/jdk/pull/2899 From dholmes at openjdk.java.net Thu Apr 8 09:25:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 09:25:48 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v2] In-Reply-To: References: Message-ID: > The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". > > The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. > > We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. > > Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). > > Some missing CHECK_ uses were added. > > Testing: > - tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fixed CHECK on return statement. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3394/files - new: https://git.openjdk.java.net/jdk/pull/3394/files/78298e5f..1adf0fd0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3394&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3394&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3394.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3394/head:pull/3394 PR: https://git.openjdk.java.net/jdk/pull/3394 From david.holmes at oracle.com Thu Apr 8 09:37:07 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Apr 2021 19:37:07 +1000 Subject: Appropriate way to delete NonJavaThread objects? In-Reply-To: References: Message-ID: <5419ce1e-6a78-03fd-83ac-5b66becf401e@oracle.com> Hi, On 8/04/2021 4:56 pm, Liu, Xin wrote: > Hi, Hotspot developers, > > I have a question about NonJavaThread destructor. Currently, there are > some NonJavaThread subclasses. Here is a simple class hierarchy. > > Thread > NonJavaThrea > NamedThread > WorkerThread > VMThread > WatcherThread > JfrThreadSampler > > I found some subclasses of NonJavaThread disallow > destruction. Eg. VMThread and WatcherThread simply abort. > // No destruction allowed > ~VMThread() { > guarantee(false, "VMThread deletion must fix the race with VM termination"); > } > > Is it absolutely no resource leak if we skip ~Thread()? I know > Linux/FreeBSD guarantee to reclaim anything when a process is > terminated, but is it true for other platforms? > > Putting aside resource leak, I don't think all NonJavaThread > subclasses necessarily have same lifecycle of JVM. Current > NonJavaThread implementation seems to inhibit from complete > destruction. eg. JfrThreadSampler uses the following approach to > delete itself. > > void JfrThreadSampler::post_run() { > this->NonJavaThread::post_run(); > delete this; > } > > I think this code is correct, but it is fragile because > NonJavaThread::post_run() nullifies Thread::clear_thread_current() > before Thread::~Thread(). "delete this" will hit the assertion of > Thread::current() at this statement. > // osthread() can be NULL, if creation of thread failed. > if (osthread() != NULL) os::free_thread(osthread()) > > > Does it matter if we ignore all destructions of NonJavaThread objects? > If the answer is no, is there an appropriate way to delete them? The lifecycle of nonJavaThreads is a bit of mix. But for those that live as long as the VM there is no need to go through a termination process in the general case, and for others there must not be a termination process (eg. the VMThread holds the Threads_lock when the VM terminates, to ensure the VM remains at a safepoint during termination, so that thread cannot die as we risk hitting thread library assertions or other undefined behaviour if a lock is held by a dead thread). By-and-large we don't care because the process will be blown away and all resources reclaimed (any platform that didn't ensure this would have a lot of problems to deal with). When the VM is hosted there can be resource leaks, but the threads themselves are only a tiny part of the resources the VM leaks in that case. NonJavaThreads that have a different lifecycle to the VM (a fairly recent situation) should cleanly terminate and destroy themselves, but you'd have to examine these on a case by case basis. And it may need adjustments to the inherited post_run() actions as you note. Cheers, David > Thanks, > --lx > > > From dholmes at openjdk.java.net Thu Apr 8 10:06:17 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 10:06:17 GMT Subject: RFR: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 15:34:31 GMT, Coleen Phillimore wrote: >> Added a flag so that thread 2 will notify thread 1 after it's waiting, and not before. >> Ran 100x on macosx-x64-debug without timeout (actually ran original 100x without timeout also). >> The test relies on one thread waiting at a place where another can find the class loading in progress. Alternate suggestions welcome. >> Thanks! >> Coleen > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add volatile Hi Coleen, The synchronization in this test is highly suspect, but your change certainly helps address one of the race conditions. Thanks, David test/hotspot/jtreg/runtime/ParallelLoad/MyLoader.java line 64: > 62: private Object sync = new Object(); > 63: private Object thread_sync = new Object(); > 64: private static volatile boolean ready = false; The name "waiting" would be more appropriate. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3375 From dholmes at openjdk.java.net Thu Apr 8 10:18:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 10:18:11 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 21:43:48 GMT, Vladimir Ivanov wrote: >> Turn `resolved_method` parameter into raw `Method*`. >> >> Testing: >> * [x] hs-tier1 - hs-tier6 > > Vladimir Ivanov 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 branch 'master' into 8264732.vtable_index_of_interface_method > - Move itable_index_of_interface_method() implementation to InstanceKlass > - Revert jvmciCompilerToVM.cpp change. > - LinkResolver::vtable_index_of_interface_method Refactoring looks good. I second Coleen's comment about unnecessary classname qualification and use of this-> Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3346 From david.holmes at oracle.com Thu Apr 8 10:19:21 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Apr 2021 20:19:21 +1000 Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On 8/04/2021 4:04 pm, Yi Yang wrote: > On Thu, 8 Apr 2021 05:38:56 GMT, David Holmes wrote: >> The UseNewCode flags are there as a development aid so that you can >> conditionally enable changed logic during development without needing to >> add a new runtime flag just for that. It can be very useful for gating >> changes when doing performance runs. No code ever gets committed that >> actually uses them though. >> >> So no, please do not delete them. :) >> >> Thanks, >> David > > Got it. Thank you David, you are the OpenJDK encyclopedia. :) > (PS: it looks like they are wrongly marked as product flags) No that is deliberate as well. Lets say I'm doing a performance test on two variants of a fix. I use UseNewCode to select between them, but I want to do the performance run on a product build. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3393 > From vlivanov at openjdk.java.net Thu Apr 8 10:30:43 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 8 Apr 2021 10:30:43 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v5] In-Reply-To: References: Message-ID: > Turn `resolved_method` parameter into raw `Method*`. > > Testing: > * [x] hs-tier1 - hs-tier6 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: InstanceKlass::method_at_itable_or_null() cleanups ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3346/files - new: https://git.openjdk.java.net/jdk/pull/3346/files/b6737c15..b5aaf41e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3346&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3346&range=03-04 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3346/head:pull/3346 PR: https://git.openjdk.java.net/jdk/pull/3346 From vlivanov at openjdk.java.net Thu Apr 8 10:33:22 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 8 Apr 2021 10:33:22 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 10:14:51 GMT, David Holmes wrote: >> Vladimir Ivanov 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 branch 'master' into 8264732.vtable_index_of_interface_method >> - Move itable_index_of_interface_method() implementation to InstanceKlass >> - Revert jvmciCompilerToVM.cpp change. >> - LinkResolver::vtable_index_of_interface_method > > Refactoring looks good. > > I second Coleen's comment about unnecessary classname qualification and use of this-> > > Thanks, > David Thanks for the reviews, Lois, Coleen, and David. ------------- PR: https://git.openjdk.java.net/jdk/pull/3346 From vlivanov at openjdk.java.net Thu Apr 8 10:33:23 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 8 Apr 2021 10:33:23 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 23:00:46 GMT, Coleen Phillimore wrote: > It doesn't need InstanceKlass:: before find_method_index, or the this->'s. Fixed. It looked clearer to me to explicitly refer to `this`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3346 From coleenp at openjdk.java.net Thu Apr 8 11:41:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 11:41:07 GMT Subject: RFR: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out [v2] In-Reply-To: References: Message-ID: <5gCcaJlsUiM9Mi-Z6bma3orXu_C6kDFr4-AnFsKt83g=.74b412f9-cfb4-4ec9-bf34-14757f13079b@github.com> On Thu, 8 Apr 2021 10:01:37 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add volatile > > test/hotspot/jtreg/runtime/ParallelLoad/MyLoader.java line 64: > >> 62: private Object sync = new Object(); >> 63: private Object thread_sync = new Object(); >> 64: private static volatile boolean ready = false; > > The name "waiting" would be more appropriate. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/3375 From coleenp at openjdk.java.net Thu Apr 8 11:47:50 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 11:47:50 GMT Subject: RFR: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out [v3] In-Reply-To: References: Message-ID: <922QJ30UV2D5-LSv1V8nFH6AjCyJ3XiJRkgjiNGfcCM=.fb8ad3f8-1dd4-42d0-b746-3dac6c6ca6b2@github.com> > Added a flag so that thread 2 will notify thread 1 after it's waiting, and not before. > Ran 100x on macosx-x64-debug without timeout (actually ran original 100x without timeout also). > The test relies on one thread waiting at a place where another can find the class loading in progress. Alternate suggestions welcome. > Thanks! > Coleen Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: rename ready to waiting ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3375/files - new: https://git.openjdk.java.net/jdk/pull/3375/files/5958bdcb..0048f355 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3375&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3375&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3375.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3375/head:pull/3375 PR: https://git.openjdk.java.net/jdk/pull/3375 From coleenp at openjdk.java.net Thu Apr 8 11:47:53 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 11:47:53 GMT Subject: RFR: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out [v2] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 10:03:23 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add volatile > > Hi Coleen, > > The synchronization in this test is highly suspect, but your change certainly helps address one of the race conditions. > > Thanks, > David Hopefully the synchronization will be more reliable with this change. I'll watch for problems with this test. Thanks for the reviews, Lois, Harold and David. ------------- PR: https://git.openjdk.java.net/jdk/pull/3375 From coleenp at openjdk.java.net Thu Apr 8 11:47:54 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 11:47:54 GMT Subject: Integrated: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out In-Reply-To: References: Message-ID: <-rvKTfNYXmTtk8TpRQAm1WGKb7bT6w5IhxCKOVX7taU=.0d844b91-e842-4cb5-8e93-08af917fbf98@github.com> On Wed, 7 Apr 2021 12:53:30 GMT, Coleen Phillimore wrote: > Added a flag so that thread 2 will notify thread 1 after it's waiting, and not before. > Ran 100x on macosx-x64-debug without timeout (actually ran original 100x without timeout also). > The test relies on one thread waiting at a place where another can find the class loading in progress. Alternate suggestions welcome. > Thanks! > Coleen This pull request has now been integrated. Changeset: 255afbea Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/255afbea Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out Reviewed-by: hseigel, lfoltan, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3375 From coleenp at openjdk.java.net Thu Apr 8 11:49:16 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 11:49:16 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > MemProfiler is a very old development option added at: > > ^As 00018/00000/00000 > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > ^Ac date and time created 98/04/14 13:18:32 by renes > ^Ae > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. > > Thanks! > Yang Thank you for finding and removing this code. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3393 From coleenp at openjdk.java.net Thu Apr 8 13:03:20 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 13:03:20 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v2] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 09:25:48 GMT, David Holmes wrote: >> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". >> >> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. >> >> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. >> >> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). >> >> Some missing CHECK_ uses were added. >> >> Testing: >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fixed CHECK on return statement. I think substituting "JavaThread* thread" for "JavaThread* current" is a good change and convention that makes the code more clear, so worth the dull code review and diffs. src/hotspot/share/c1/c1_Runtime1.cpp line 180: > 178: static void deopt_caller() { > 179: if ( !caller_is_deopted()) { > 180: JavaThread* current = JavaThread::current(); It looks like both of these functions could be passed JavaThread from the callers. You could leave this as a cleanup though. It would eliminate two explicit JavaThread::current calls. src/hotspot/share/c1/c1_Runtime1.cpp line 414: > 412: assert(klass->is_klass(), "not a class"); > 413: assert(rank >= 1, "rank must be nonzero"); > 414: Handle holder(current, klass->klass_holder()); // keep the klass alive I think this is ok now, since current is obviously the current thread. There doesn't seem to be a need to use THREAD here. I don't know about changing all the uses of THREAD to current for Handles/methodHandles/ResourceMark/HandleMark but this seems ok in this context since JavaThread* current is present. src/hotspot/share/c1/c1_Runtime1.cpp line 695: > 693: NOT_PRODUCT(_throw_class_cast_exception_count++;) > 694: ResourceMark rm(current); > 695: char* message = SharedRuntime::generate_class_cast_message(current, object->klass()); Is this indentation off? src/hotspot/share/interpreter/interpreterRuntime.cpp line 1157: > 1155: JRT_END > 1156: > 1157: JRT_ENTRY(void, InterpreterRuntime::post_field_access(JavaThread *current, oopDesc* obj, nit: JavaThread* current src/hotspot/share/interpreter/interpreterRuntime.cpp line 1237: > 1235: JRT_END > 1236: > 1237: JRT_ENTRY(void, InterpreterRuntime::post_method_entry(JavaThread *current)) Also move the star here and one below. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3394 From hseigel at openjdk.java.net Thu Apr 8 13:16:26 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 8 Apr 2021 13:16:26 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v2] In-Reply-To: References: Message-ID: <4IppJ2wYSTxcAKq1z7iSB8fxmmtDSlFimFFSJs9no5g=.29e6b187-a81b-4f9f-afd1-0ce0e9b956f7@github.com> On Thu, 8 Apr 2021 09:25:48 GMT, David Holmes wrote: >> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". >> >> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. >> >> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. >> >> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). >> >> Some missing CHECK_ uses were added. >> >> Testing: >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fixed CHECK on return statement. src/hotspot/share/interpreter/interpreterRuntime.cpp line 303: > 301: // We'd expect to assert that we're only here to quicken bytecodes, but in a multithreaded > 302: // program we might have seen an unquick'd bytecode in the interpreter but have another > 303: // current quicken the bytecode before we get here. This should still say 'thread', not 'current' ------------- PR: https://git.openjdk.java.net/jdk/pull/3394 From dholmes at openjdk.java.net Thu Apr 8 13:16:25 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 13:16:25 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v2] In-Reply-To: References: Message-ID: <2fThFbhrFCVWjj4KuHJyYtHl47kKuyrBTwkiZFqDQ9c=.2abb180f-479d-4776-aada-6235359d23b9@github.com> On Thu, 8 Apr 2021 13:00:03 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed CHECK on return statement. > > I think substituting "JavaThread* thread" for "JavaThread* current" is a good change and convention that makes the code more clear, so worth the dull code review and diffs. Looks like I missed some definitions that aren't included in our test builds but have been found via GHA builds. I will rectify those and update. ------------- PR: https://git.openjdk.java.net/jdk/pull/3394 From hseigel at openjdk.java.net Thu Apr 8 15:07:14 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 8 Apr 2021 15:07:14 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Thu, 8 Apr 2021 04:38:37 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. The other whole bigger big will be fixed in the other issue. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > add throw exception Class HostNoNestMember could be removed entirely from class TestNestHostErrorWithMultiThread by doing the following: Generate a jcod representation for class HostNoNestMember$Member and add it to HostNoNestMember.jcod. Delete class HostNoNestMember from TestNestHostErrorWithMultiThread.java. Change the test to compile HostNoNestMember.jcod before compiling TestNestHostErrorWithMultiThread.java. Doing this removes the confusion of class HostNoNestMember being compiled twice. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From rrich at openjdk.java.net Thu Apr 8 16:13:34 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 8 Apr 2021 16:13:34 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 07:17:48 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - White space fixes > - Merge branch 'master' into SuspendInHandshake > - Review fixes > - Merge branch 'master' into SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - 8257831: Suspend with handshake (review baseline) Hi Robbin, thanks for the update. This is almost ready to be pushed from my pov. Richard. src/hotspot/share/runtime/handshake.cpp line 630: > 628: // exiting. > 629: } > 630: } I need a little help learning the steps of this dance :) We reach here in _thread_in_vm. We cannot be suspended in this state. There might be another thread waiting to handshake us to suspend us but why can't we just ignore that and do the `_handshakee->set_exiting();` even without locking HandshakeState::_lock? Adding a handshake operation is lock free, so even if the check `SafepointMechanism::should_process(_handshakee)` in L619 returns false a new operation to process could have been added concurrently such that `SafepointMechanism::should_process(_handshakee)` would return true when we execute `_handshakee->set_exiting();` in L620. What am I missing? ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From xxinliu at amazon.com Thu Apr 8 18:55:58 2021 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 8 Apr 2021 18:55:58 +0000 Subject: Appropriate way to delete NonJavaThread objects? In-Reply-To: <5419ce1e-6a78-03fd-83ac-5b66becf401e@oracle.com> References: <5419ce1e-6a78-03fd-83ac-5b66becf401e@oracle.com> Message-ID: <69E83374-4FDE-48E4-BB99-2CA14063A368@amazon.com> Hi, David, Got it. Thank you for sharing your experiences. I don't know hotspot has to deal with thread library's constraints. Fair enough. I don't know much about JfrThreadSampler. Leave it for future investigation. Thanks, --lx ? From dholmes at openjdk.java.net Thu Apr 8 23:22:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 23:22:12 GMT Subject: RFR: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() [v5] In-Reply-To: References: Message-ID: <4hlErrA1RgyMdHl6UEKrrd7idmaS_fSEQY1Q-l-PmS4=.37f32827-7e23-4cef-928b-1c142a8d2a2d@github.com> On Thu, 8 Apr 2021 10:30:43 GMT, Vladimir Ivanov wrote: >> Turn `resolved_method` parameter into raw `Method*`. >> >> Testing: >> * [x] hs-tier1 - hs-tier6 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > InstanceKlass::method_at_itable_or_null() cleanups Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3346 From dholmes at openjdk.java.net Thu Apr 8 23:40:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 23:40:18 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v2] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 12:18:12 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed CHECK on return statement. > > src/hotspot/share/c1/c1_Runtime1.cpp line 180: > >> 178: static void deopt_caller() { >> 179: if ( !caller_is_deopted()) { >> 180: JavaThread* current = JavaThread::current(); > > It looks like both of these functions could be passed JavaThread from the callers. You could leave this as a cleanup though. It would eliminate two explicit JavaThread::current calls. That's a good additional cleanup - thanks. Fixed. > src/hotspot/share/c1/c1_Runtime1.cpp line 695: > >> 693: NOT_PRODUCT(_throw_class_cast_exception_count++;) >> 694: ResourceMark rm(current); >> 695: char* message = SharedRuntime::generate_class_cast_message(current, object->klass()); > > Is this indentation off? Fixed. (My emacs can't figure out how to indent when these macros are used. :( ) > src/hotspot/share/interpreter/interpreterRuntime.cpp line 1157: > >> 1155: JRT_END >> 1156: >> 1157: JRT_ENTRY(void, InterpreterRuntime::post_field_access(JavaThread *current, oopDesc* obj, > > nit: JavaThread* current Fixed > src/hotspot/share/interpreter/interpreterRuntime.cpp line 1237: > >> 1235: JRT_END >> 1236: >> 1237: JRT_ENTRY(void, InterpreterRuntime::post_method_entry(JavaThread *current)) > > Also move the star here and one below. Fixed all. ------------- PR: https://git.openjdk.java.net/jdk/pull/3394 From dholmes at openjdk.java.net Thu Apr 8 23:40:19 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 23:40:19 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v2] In-Reply-To: <4IppJ2wYSTxcAKq1z7iSB8fxmmtDSlFimFFSJs9no5g=.29e6b187-a81b-4f9f-afd1-0ce0e9b956f7@github.com> References: <4IppJ2wYSTxcAKq1z7iSB8fxmmtDSlFimFFSJs9no5g=.29e6b187-a81b-4f9f-afd1-0ce0e9b956f7@github.com> Message-ID: On Thu, 8 Apr 2021 13:11:36 GMT, Harold Seigel wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed CHECK on return statement. > > src/hotspot/share/interpreter/interpreterRuntime.cpp line 303: > >> 301: // We'd expect to assert that we're only here to quicken bytecodes, but in a multithreaded >> 302: // program we might have seen an unquick'd bytecode in the interpreter but have another >> 303: // current quicken the bytecode before we get here. > > This should still say 'thread', not 'current' Well spotted! Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3394 From dholmes at openjdk.java.net Thu Apr 8 23:45:40 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 23:45:40 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v3] In-Reply-To: References: Message-ID: > The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". > > The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. > > We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. > > Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). > > Some missing CHECK_ uses were added. > > Testing: > - tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with three additional commits since the last revision: - Fix minor nits reported by @coleenp and @hseigel - @coleenp review comment - Avoid manifesting JavaThread::current() when it can be passed in - Added in missed JRT_BLOCK_ENTRY methods in AOT-related jvmci/compilerRuntime.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3394/files - new: https://git.openjdk.java.net/jdk/pull/3394/files/1adf0fd0..041d7ef5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3394&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3394&range=01-02 Stats: 71 lines in 5 files changed: 1 ins; 2 del; 68 mod Patch: https://git.openjdk.java.net/jdk/pull/3394.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3394/head:pull/3394 PR: https://git.openjdk.java.net/jdk/pull/3394 From yyang at openjdk.java.net Fri Apr 9 02:13:15 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 9 Apr 2021 02:13:15 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 05:38:56 GMT, David Holmes wrote: >> MemProfiler is a very old development option added at: >> >> ^As 00018/00000/00000 >> ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 >> ^Ac date and time created 98/04/14 13:18:32 by renes >> ^Ae >> >> Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. >> >> After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. >> >> Thanks! >> Yang > > Hi Yi, > > Actual code removal looks good. > > Thanks, > David Thanks @dholmes-ora @coleenp for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3393 From dholmes at openjdk.java.net Fri Apr 9 05:08:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 9 Apr 2021 05:08:37 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v4] In-Reply-To: References: Message-ID: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> > The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". > > The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. > > We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. > > Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). > > Some missing CHECK_ uses were added. > > Testing: > - tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fix search&replace mistake ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3394/files - new: https://git.openjdk.java.net/jdk/pull/3394/files/041d7ef5..9cfc43c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3394&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3394&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3394.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3394/head:pull/3394 PR: https://git.openjdk.java.net/jdk/pull/3394 From sspitsyn at openjdk.java.net Fri Apr 9 06:24:29 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 9 Apr 2021 06:24:29 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 16:09:52 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 six commits: >> >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > Hi Robbin, > > thanks for the update. This is almost ready to be pushed from my pov. > > Richard. Hi Robbin, Just a couple of comments below. src/hotspot/share/runtime/handshake.hpp 154 // This flag is true while there is async handshake (trap) 155 // on queue. Since we do only need one, we can reuse it if 156 // thread thread gets suspended again (after a resume) 157 // and have not yet processed it. 158 bool _async_suspend_handshake; A couple of nits above: L156: "thread thread" => "thread" L157: "and have not yet processed it." => "and we have not yet processed it." src/hotspot/share/runtime/handshake.cpp 658 bool HandshakeState::suspend_with_handshake() { . . . 684 ThreadSuspensionHandshake* ts = new ThreadSuspensionHandshake(); 685 Handshake::execute(ts, _handshakee); I wonder why ThreadSuspensionHandshake is not stack allocated as SuspendThreadHandshake below: 701 bool HandshakeState::suspend() { 702 SuspendThreadHandshake st; 703 Handshake::execute(&st, _handshakee); Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From shade at openjdk.java.net Fri Apr 9 06:26:16 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Apr 2021 06:26:16 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > MemProfiler is a very old development option added at: > > ^As 00018/00000/00000 > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > ^Ac date and time created 98/04/14 13:18:32 by renes > ^Ae > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. > > Thanks! > Yang Looks fine to me as well. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3393 From yyang at openjdk.java.net Fri Apr 9 06:26:16 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 9 Apr 2021 06:26:16 GMT Subject: Integrated: 8264881: Remove the old development option MemProfiling In-Reply-To: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > MemProfiler is a very old development option added at: > > ^As 00018/00000/00000 > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > ^Ac date and time created 98/04/14 13:18:32 by renes > ^Ae > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. > > Thanks! > Yang This pull request has now been integrated. Changeset: 666fd62e Author: Yi Yang Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/666fd62e Stats: 201 lines in 8 files changed: 0 ins; 201 del; 0 mod 8264881: Remove the old development option MemProfiling Reviewed-by: dholmes, coleenp, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/3393 From yyang at openjdk.java.net Fri Apr 9 07:18:24 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 9 Apr 2021 07:18:24 GMT Subject: Withdrawn: 8264682: MemProfiling does not own Heap_lock when using G1 In-Reply-To: References: Message-ID: <22s7OOLgMBFF1tkEbH8vNgr7fuOFcPjNJNjn-U7t5CI=.ab0ee64e-1e2e-4d9a-b734-451d61f71f6a@github.com> On Mon, 5 Apr 2021 07:34:30 GMT, Yi Yang wrote: > Trivial fix for JDK-8264682. > > `Universe::heap()->used()` calls G1Allocator::used_in_alloc_regions() when G1 enabled, it checks whether Heap_lock was owned on this thread's behalf. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3340 From vlivanov at openjdk.java.net Fri Apr 9 11:39:25 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 9 Apr 2021 11:39:25 GMT Subject: Integrated: 8264732: Clean up LinkResolver::vtable_index_of_interface_method() In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 18:01:15 GMT, Vladimir Ivanov wrote: > Turn `resolved_method` parameter into raw `Method*`. > > Testing: > * [x] hs-tier1 - hs-tier6 This pull request has now been integrated. Changeset: 33fa855d Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk/commit/33fa855d Stats: 55 lines in 3 files changed: 29 ins; 23 del; 3 mod 8264732: Clean up LinkResolver::vtable_index_of_interface_method() Reviewed-by: lfoltan, coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3346 From jiefu at openjdk.java.net Fri Apr 9 12:41:23 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 9 Apr 2021 12:41:23 GMT Subject: RFR: 8264008: Incorrect metaspace statistics after JEP 387 when UseCompressedClassPointers is off [v3] In-Reply-To: References: Message-ID: <8QzIEF7RuZCcuqx2_lyCTuYvJUcUObjDIQRwDwpW6ik=.ef061235-583b-4882-90db-d36f41f4d911@github.com> On Tue, 23 Mar 2021 06:35:24 GMT, Thomas Stuefe wrote: > Even better would be an own regression test, e.g. as part of the gtests. Can be very simple, if UseCompressedClassPointers is off, MetaspaceUtils::committed_words should return 0 for class type. Then we can add another gtest run to the gtest runner jtreg tests with that option (possibly in a separate RFE). Hi @tstuefe , The gtest has been added here: https://github.com/openjdk/jdk/pull/3414 . Please review it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3142 From jiefu at openjdk.java.net Fri Apr 9 12:41:36 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 9 Apr 2021 12:41:36 GMT Subject: RFR: 8264983: Add gtest for JDK-8264008 Message-ID: Hi all, Here is the gtest for JDK-8264008 as discussed here: https://github.com/openjdk/jdk/pull/3142#pullrequestreview-618244082 . Any comments? Testing: - test/hotspot/jtreg/gtest/MetaspaceUtilsGtests.java on Linux/{x64,x86_32} and macOSX Thanks. Best regards, Jie ------------- Commit messages: - 8264983: Add gtest for JDK-8264008 Changes: https://git.openjdk.java.net/jdk/pull/3414/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3414&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264983 Stats: 55 lines in 2 files changed: 55 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3414.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3414/head:pull/3414 PR: https://git.openjdk.java.net/jdk/pull/3414 From hseigel at openjdk.java.net Fri Apr 9 13:43:18 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 9 Apr 2021 13:43:18 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v4] In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> References: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> Message-ID: On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes wrote: >> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". >> >> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. >> >> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. >> >> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). >> >> Some missing CHECK_ uses were added. >> >> Testing: >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix search&replace mistake Nice big cleanup! LGTM Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3394 From shade at openjdk.java.net Fri Apr 9 15:00:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Apr 2021 15:00:53 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels Message-ID: See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. Additional testing: - [x] Test with kernel 5.4.0 (still passes) - [x] Test with kernel 4.9.0 (used to fail, now passes) ------------- Commit messages: - Make jcheck happy: remove the TAB - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels Changes: https://git.openjdk.java.net/jdk/pull/3415/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3415&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263236 Stats: 62 lines in 1 file changed: 40 ins; 1 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/3415.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3415/head:pull/3415 PR: https://git.openjdk.java.net/jdk/pull/3415 From dcubed at openjdk.java.net Fri Apr 9 15:05:20 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 9 Apr 2021 15:05:20 GMT Subject: Integrated: 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI In-Reply-To: References: Message-ID: <9qxyrScT3Cqe9bdD5J67jEa6onF7X8rur8_uzcjLXwA=.5d2efa94-a4d3-434a-bad6-06ea5d5cea9b@github.com> On Tue, 9 Mar 2021 21:08:54 GMT, Daniel D. Daugherty wrote: > Add three tests from JDK-4413752 ported to JVM/TI: > > - RawMonitorEnter() with SuspendThread() > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/SuspendWithRawMonitorEnter.java > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp > > - ObjectMonitor enter() with SuspendThread() > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/SuspendWithObjectMonitorEnter.java > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp > > - ObjectMonitor wait() with SuspendThread > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java > - test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp > > The Java files have a transaction diagram to show what each of the > threads in the test is doing. This pull request has now been integrated. Changeset: 1ca4abe9 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/1ca4abe9 Stats: 1501 lines in 6 files changed: 1501 ins; 0 del; 0 mod 8262881: port JVM/DI tests from JDK-4413752 to JVM/TI Reviewed-by: sspitsyn, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/2899 From coleenp at openjdk.java.net Fri Apr 9 15:52:49 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 15:52:49 GMT Subject: RFR: 8264997: Remove SystemDictionary::cache_get Message-ID: This is a trivial change to remove an unneeded function in SystemDictionary. The pd_cache_table() that is owned by SystemDictionary is already available to callers of SystemDictionary, ie. the ServiceThread, so there's no need to hide access inside of a function with a backwards name. I also fixed add_protection_domain logging to be useful and fixed an assert. Tested with mach5 tier1-3 in progress and manually. ------------- Commit messages: - 8264997: Remove SystemDictionary::cache_get Changes: https://git.openjdk.java.net/jdk/pull/3418/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3418&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264997 Stats: 19 lines in 4 files changed: 7 ins; 7 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3418.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3418/head:pull/3418 PR: https://git.openjdk.java.net/jdk/pull/3418 From dcubed at openjdk.java.net Fri Apr 9 16:19:38 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 9 Apr 2021 16:19:38 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: Message-ID: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> On Thu, 8 Apr 2021 07:17:48 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - White space fixes > - Merge branch 'master' into SuspendInHandshake > - Review fixes > - Merge branch 'master' into SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - 8257831: Suspend with handshake (review baseline) I'm still really happy with this fix! Thumbs up! Reminder: don't forget to decide what to do about the obsolete options. @dholmes-ora can provide guidance on how to handle this type of removal. src/hotspot/share/runtime/handshake.cpp line 632: > 630: } > 631: > 632: void HandshakeState::self_suspened() { Typo: s/self_suspened/self_suspended/ src/hotspot/share/runtime/handshake.cpp line 654: > 652: void do_thread(Thread* thr) { > 653: JavaThread* target = thr->as_Java_thread(); > 654: target->handshake_state()->self_suspened(); Typo: s/self_suspened/self_suspended/ src/hotspot/share/runtime/handshake.hpp line 131: > 129: return true; > 130: } > 131: OrderAccess::loadload(); Needs a comment explaining what the memory sync is for. src/hotspot/share/runtime/handshake.hpp line 156: > 154: // This flag is true while there is async handshake (trap) > 155: // on queue. Since we do only need one, we can reuse it if > 156: // thread thread gets suspended again (after a resume) typo: s/thread thread/thread/ src/hotspot/share/runtime/objectMonitor.cpp line 410: > 408: > 409: current->frame_anchor()->make_walkable(current); > 410: OrderAccess::storestore(); Needs a comment explaining what the memory sync is for. src/hotspot/share/runtime/objectMonitor.cpp line 970: > 968: > 969: current->frame_anchor()->make_walkable(current); > 970: OrderAccess::storestore(); Needs a comment explaining what the memory sync is for. src/hotspot/share/runtime/objectMonitor.cpp line 977: > 975: if (_succ == current) { > 976: _succ = NULL; > 977: OrderAccess::fence(); Please add a comment to this line: `OrderAccess::fence(); // always do a full fence when successor is cleared` src/hotspot/share/runtime/objectMonitor.cpp line 1540: > 1538: { > 1539: current->frame_anchor()->make_walkable(current); > 1540: OrderAccess::storestore(); Needs a comment explaining what the memory sync is for. src/hotspot/share/runtime/objectMonitor.cpp line 1555: > 1553: if (_succ == current) { > 1554: _succ = NULL; > 1555: OrderAccess::fence(); Please add a comment to this line: OrderAccess::fence(); // always do a full fence when successor is cleared src/hotspot/share/runtime/thread.cpp line 455: > 453: ParkEvent::Release(_ParkEvent); > 454: // Can be racingly loaded in signal handler via has_terminated() > 455: Atomic::store(&_ParkEvent, (ParkEvent*)NULL); Nice solution for that odd signal handler issue. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Fri Apr 9 16:19:39 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 9 Apr 2021 16:19:39 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 07:23:26 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/handshake.cpp line 415: >> >>> 413: // Adds are done lock free and so is arming. >>> 414: // Calling this method with lock held is considered an error. >>> 415: assert(!_lock.owned_by_self(), "Lock should not be held"); >> >> If adds are still lock-free then why was this assertion removed? > > Because we add the async handshake inside the sync handshake and thus we already hold the _lock. Doesn't that mean the comment on L415 needs updating? Should it be something like: // Synchronous adds are done lock free and so is arming, but some // asynchronous adds are done when we already hold the lock. I'm not sure about the "some asynchronous adds" part... ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Fri Apr 9 16:19:41 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 9 Apr 2021 16:19:41 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 16:08:06 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 six commits: >> >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.cpp line 630: > >> 628: // exiting. >> 629: } >> 630: } > > I need a little help learning the steps of this dance :) > > We reach here in _thread_in_vm. We cannot be suspended in this state. There > might be another thread waiting to handshake us to suspend us but why can't we > just ignore that and do the `_handshakee->set_exiting();` even without locking > HandshakeState::_lock? > > Adding a handshake operation is lock free, so even if the check > `SafepointMechanism::should_process(_handshakee)` in L619 returns false a new > operation to process could have been added concurrently such that > `SafepointMechanism::should_process(_handshakee)` would return true when we > execute `_handshakee->set_exiting();` in L620. What am I missing? `HandshakeState::suspend()` is a synchronous handshake and adding the handshake to the queue is lock free, but the execution of the synchronous handshake itself requires a `HandshakeState::claim_handshake()` call which does acquire the lock in question. We (the suspend requester) hold the lock while the handshake is being processed so we either detect that _handshakee->set_exiting() won the race (in the target thread) or we (the suspend requester) win the race of setting the suspend flag so the target thread can't exit yet. Hopefully that helps explain this dance. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Fri Apr 9 16:19:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 9 Apr 2021 16:19:42 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> References: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> Message-ID: On Fri, 9 Apr 2021 15:29:30 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 six commits: >> >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.cpp line 632: > >> 630: } >> 631: >> 632: void HandshakeState::self_suspened() { > > Typo: s/self_suspened/self_suspended/ I'm not fond of `self_suspended` as the function name. Perhaps `do_self_suspend` or something like that... (What color would you like that bike shed?) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Fri Apr 9 16:19:40 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 9 Apr 2021 16:19:40 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 07:25:29 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/handshake.cpp line 463: >> >>> 461: ThreadInVMForHandshake tivm(_handshakee); >>> 462: { >>> 463: ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); >> >> Why is this needed when it is inside ThreadInVMForHandshake constructor ?? > > If we process the async suspension handshake we can go to safepoint. > And before safepoint we must drop the tty lock. Is this worth a comment above the `break_tty_lock_for_safepoint()` call? >> src/hotspot/share/runtime/thread.cpp line 1442: >> >>> 1440: >>> 1441: // The careful dance between thread suspension and exit is handled here: >>> 1442: _handshake.thread_exit(); >> >> I don't like the fact this hides the set_terminating call. >> >> In fact I think I'd rather keep this in-line rather than tucking it away inside the handshake code. This looks too much like we're informing the handshake that the thread is exiting rather then coordinating thread termination with a late suspension request. > > The problem is that we need access to the private _lock to coordinate this. Perhaps rename the function to something like handle_thread_exit_race()? ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From gziemski at openjdk.java.net Fri Apr 9 16:28:19 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 9 Apr 2021 16:28:19 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 02:03:15 GMT, Yasumasa Suenaga wrote: >> `jdk.CPUInformation` event on AArch64 has valid CPU description in [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491), however it does not work on UEFI booted machine. >> >> [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491) refers device tree to get board name, however it does not exist on UEFI. We need to refer DMI. >> However we need to have root privilege, so we refer /sys/devices/virtual/dmi/id to avoid it. >> >> We can get board name from /sys/devices/virtual/dmi/id/board_name, but some machine set empty string to it. So we will refer /sys/devices/virtual/dmi/id/product_name as a fallback. >> >> For example, we can get following CPU description on AWS A1 instance after this change: >> >> jdk.CPUInformation { >> startTime = 05:28:24.506 >> cpu = "AArch64" >> description = "AArch64 a1.2xlarge 0x41:0x0:0xd08:3, simd, crc, aes, sha1, sha256" >> sockets = 8 >> cores = 8 >> hwThreads = 8 >> } > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > check the contents whether it is just "\n" Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From sspitsyn at openjdk.java.net Fri Apr 9 17:26:22 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 9 Apr 2021 17:26:22 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> Message-ID: On Fri, 9 Apr 2021 16:15:28 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/handshake.cpp line 632: >> >>> 630: } >>> 631: >>> 632: void HandshakeState::self_suspened() { >> >> Typo: s/self_suspened/self_suspended/ > > I'm not fond of `self_suspended` as the function name. > Perhaps `do_self_suspend` or something like that... > (What color would you like that bike shed?) I like the suggestion to rename self_suspened to do_self_suspend. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From coleenp at openjdk.java.net Fri Apr 9 18:31:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 18:31:48 GMT Subject: RFR: 8264997: Remove SystemDictionary::cache_get [v2] In-Reply-To: References: Message-ID: <7GkthHnDMaW1LeMvhuTkn-Pop1sAcb3JR7SZ67xq0mY=.a39576aa-43f7-4876-97a1-ec79da893e93@github.com> > This is a trivial change to remove an unneeded function in SystemDictionary. The pd_cache_table() that is owned by SystemDictionary is already available to callers of SystemDictionary, ie. the ServiceThread, so there's no need to hide access inside of a function with a backwards name. > > I also fixed add_protection_domain logging to be useful and fixed an assert. > > Tested with mach5 tier1-3 in progress and manually. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Missed fixing logging test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3418/files - new: https://git.openjdk.java.net/jdk/pull/3418/files/9a661354..7900de31 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3418&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3418&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3418.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3418/head:pull/3418 PR: https://git.openjdk.java.net/jdk/pull/3418 From hseigel at openjdk.java.net Fri Apr 9 20:08:18 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 9 Apr 2021 20:08:18 GMT Subject: RFR: 8264997: Remove SystemDictionary::cache_get [v2] In-Reply-To: <7GkthHnDMaW1LeMvhuTkn-Pop1sAcb3JR7SZ67xq0mY=.a39576aa-43f7-4876-97a1-ec79da893e93@github.com> References: <7GkthHnDMaW1LeMvhuTkn-Pop1sAcb3JR7SZ67xq0mY=.a39576aa-43f7-4876-97a1-ec79da893e93@github.com> Message-ID: On Fri, 9 Apr 2021 18:31:48 GMT, Coleen Phillimore wrote: >> This is a trivial change to remove an unneeded function in SystemDictionary. The pd_cache_table() that is owned by SystemDictionary is already available to callers of SystemDictionary, ie. the ServiceThread, so there's no need to hide access inside of a function with a backwards name. >> >> I also fixed add_protection_domain logging to be useful and fixed an assert. >> >> Tested with mach5 tier1-3 in progress and manually. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Missed fixing logging test. These changes look good and trivial. Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3418 From coleenp at openjdk.java.net Fri Apr 9 20:50:26 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 20:50:26 GMT Subject: RFR: 8264997: Remove SystemDictionary::cache_get [v2] In-Reply-To: References: <7GkthHnDMaW1LeMvhuTkn-Pop1sAcb3JR7SZ67xq0mY=.a39576aa-43f7-4876-97a1-ec79da893e93@github.com> Message-ID: <1ezitEUnTFSLjk-Ye8iFGGtQBbriCiXVPJBFSc00JDY=.8255431e-d1d1-4b11-834f-7f8fd641cbf8@github.com> On Fri, 9 Apr 2021 20:05:35 GMT, Harold Seigel wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Missed fixing logging test. > > These changes look good and trivial. > Thanks, Harold Thanks Harold! ------------- PR: https://git.openjdk.java.net/jdk/pull/3418 From coleenp at openjdk.java.net Fri Apr 9 20:50:27 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 20:50:27 GMT Subject: Integrated: 8264997: Remove SystemDictionary::cache_get In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 15:44:30 GMT, Coleen Phillimore wrote: > This is a trivial change to remove an unneeded function in SystemDictionary. The pd_cache_table() that is owned by SystemDictionary is already available to callers of SystemDictionary, ie. the ServiceThread, so there's no need to hide access inside of a function with a backwards name. > > I also fixed add_protection_domain logging to be useful and fixed an assert. > > Tested with mach5 tier1-3 in progress and manually. This pull request has now been integrated. Changeset: f26cd2ac Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/f26cd2ac Stats: 21 lines in 5 files changed: 7 ins; 7 del; 7 mod 8264997: Remove SystemDictionary::cache_get Reviewed-by: hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/3418 From ysuenaga at openjdk.java.net Sat Apr 10 04:56:02 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 10 Apr 2021 04:56:02 GMT Subject: RFR: 8264482: container info misleads on non-container environment [v3] In-Reply-To: References: Message-ID: > hs_err log and `VM.info` dcmd shows cgroup information as container information even though the process run on non-container environment as following. > > container (cgroup) information: > container_type: cgroupv2 > cpu_cpuset_cpus: not supported > cpu_memory_nodes: not supported > active_processor_count: 4 > cpu_quota: not supported > cpu_period: not supported > cpu_shares: not supported > memory_limit_in_bytes: unlimited > memory_and_swap_limit_in_bytes: unlimited > memory_soft_limit_in_bytes: unlimited > memory_usage_in_bytes: 164163584 > memory_max_usage_in_bytes: not supported > > We can use cgroup outside of container, so it is useful to show. However cgroup is different from container. We should distinguish them. > And also it is useful if we can see container runtime in this section. So I added it. We can see following contents in this section after this change. > > cgroup information: > cgroup_type: cgroupv2 > container runtime: podman > cpu_cpuset_cpus: not supported > cpu_memory_nodes: not supported > active_processor_count: 4 > cpu_quota: not supported > cpu_period: not supported > cpu_shares: not supported > memory_limit_in_bytes: unlimited > memory_and_swap_limit_in_bytes: unlimited > memory_soft_limit_in_bytes: unlimited > memory_usage_in_bytes: 256176128 > memory_max_usage_in_bytes: not supported > > In case of systemd, it checks PID (PID 1 or not) and `$container` in PID 1. We should check them to know the JVM runs on the container or not. > > https://github.com/systemd/systemd/blob/68337e55f62cf49b7bdfb73dc5662e23b0ea17fa/src/basic/virt.c#L619 Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Use resource controller name for unified logging ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3280/files - new: https://git.openjdk.java.net/jdk/pull/3280/files/8fd9b3f9..15000e9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3280&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3280&range=01-02 Stats: 25 lines in 6 files changed: 5 ins; 3 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/3280.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3280/head:pull/3280 PR: https://git.openjdk.java.net/jdk/pull/3280 From ysuenaga at openjdk.java.net Sat Apr 10 04:59:26 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 10 Apr 2021 04:59:26 GMT Subject: RFR: 8264482: container info misleads on non-container environment [v2] In-Reply-To: References: <3xBZarV2-nFsRCB-iCLzNSE4H316QbfeZ61MHywMV9E=.215d64c5-1ad2-41df-926d-10941b734b3b@github.com> Message-ID: On Wed, 7 Apr 2021 07:23:08 GMT, Yasumasa Suenaga wrote: >>> What I'm unsure about is whether or not this is a problem worth fixing. >> >> I think fundamental solutions will be implemented in JDK-8261242, but It seems to be a difficult task. >> >>> The main idea is abstraction from cgroups in the container code. It does say `container (cgroup) information` in the heading. >> >> I know that, but "container_type" label is in hs_err / VM.info log. In addition, UL reports some metrics as "container" in spite of cgroups. >> If it takes a long time to fix JDK-8261242, I want to fix log messages for cgroups for next LTS release at least. "container" messages may make the customer do extra work to collect / analyzer their system. > >> Then can we compromise and just say "container/cgroup" everywhere? > > How about following change? > It is easy to add new resource controller other than cgroups in future. > > // get_resource_container_name() will return "cgroups" or "cgroupsV2" > const char *resource_controller_name = OSContainer::get_resource_container_name(); > > log_debug(os, container)("%s memory limit %s: " JLONG_FORMAT ", using host value", > resource_controller_name, > mem_limit == OSCONTAINER_ERROR ? "failed" : "unlimited", mem_limit); I pushed new commit to use resource controller name to show both UL and VM.info. In UL, resource controller name ("cgroupsv1" or "cgroupsv2") will be added to UL message, but the log is tagged os+container, so the user aware it might relates to the container, and they can know it says about cgroups. It has tested with test/hotspot/jtreg/containers jtreg tests on Linux x64. ------------- PR: https://git.openjdk.java.net/jdk/pull/3280 From shade at openjdk.java.net Sat Apr 10 05:59:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sat, 10 Apr 2021 05:59:43 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v2] In-Reply-To: References: Message-ID: > See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. > > Additional testing: > - [x] Test with kernel 5.4.0 (still passes) > - [x] Test with kernel 4.9.0 (used to fail, now passes) 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 three additional commits since the last revision: - Merge branch 'master' into JDK-8263236-trace-page-sizes - Make jcheck happy: remove the TAB - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3415/files - new: https://git.openjdk.java.net/jdk/pull/3415/files/43271637..6db67d61 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3415&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3415&range=00-01 Stats: 2637 lines in 54 files changed: 2301 ins; 150 del; 186 mod Patch: https://git.openjdk.java.net/jdk/pull/3415.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3415/head:pull/3415 PR: https://git.openjdk.java.net/jdk/pull/3415 From rrich at openjdk.java.net Sat Apr 10 07:41:25 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Sat, 10 Apr 2021 07:41:25 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: Message-ID: <-fsVAozVnQsZHcO1hEhjJi9oALuXdOCOg7q6wqgyvaA=.b0e4face-f58b-45ae-83ba-c6b249752272@github.com> On Fri, 9 Apr 2021 16:12:16 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/handshake.cpp line 630: >> >>> 628: // exiting. >>> 629: } >>> 630: } >> >> I need a little help learning the steps of this dance :) >> >> We reach here in _thread_in_vm. We cannot be suspended in this state. There >> might be another thread waiting to handshake us to suspend us but why can't we >> just ignore that and do the `_handshakee->set_exiting();` even without locking >> HandshakeState::_lock? >> >> Adding a handshake operation is lock free, so even if the check >> `SafepointMechanism::should_process(_handshakee)` in L619 returns false a new >> operation to process could have been added concurrently such that >> `SafepointMechanism::should_process(_handshakee)` would return true when we >> execute `_handshakee->set_exiting();` in L620. What am I missing? > > `HandshakeState::suspend()` is a synchronous handshake and adding the > handshake to the queue is lock free, but the execution of the synchronous > handshake itself requires a `HandshakeState::claim_handshake()` call which > does acquire the lock in question. We (the suspend requester) hold the lock > while the handshake is being processed so we either detect that > _handshakee->set_exiting() won the race (in the target thread) or we (the > suspend requester) win the race of setting the suspend flag so the target > thread can't exit yet. > > Hopefully that helps explain this dance. Hi Dan, thanks for picking up my question! > `HandshakeState::suspend()` is a synchronous handshake and adding the > handshake to the queue is lock free, but the execution of the synchronous > handshake itself requires a `HandshakeState::claim_handshake()` call which > does acquire the lock in question. My point would be that the attempt to execute the synchronous handshake for suspending a thread that is just about to call HandshakeState::thread_exit() cannot make progress (blocks) while the target thread is not safe (_thread_in_vm). A synchronous handshake requires the target thread to be in a safe state for the requester to execute the handshake operation. When executing HandshakeState::thread_exit() the suspendee is _thread_in_vm. And the requester will find it to be `_not_safe` when calling `possibly_can_process_handshake()` before calling `HandshakeState::claim_handshake()` or when calling `can_process_handshake()` afterwards. In both cases try_process() returns with failure _not_safe and the lock is not held. ++ 546 if (!possibly_can_process_handshake()) { 547 // JT is observed in an unsafe state, it must notice the handshake itself 548 return HandshakeState::_not_safe; 549 } 550 551 // Claim the mutex if there still an operation to be executed. 552 if (!claim_handshake()) { 553 return HandshakeState::_claim_failed; 554 } 555 556 // If we own the mutex at this point and while owning the mutex we 557 // can observe a safe state the thread cannot possibly continue without 558 // getting caught by the mutex. 559 if (!can_process_handshake()) { 560 _lock.unlock(); 561 return HandshakeState::_not_safe; 562 } So isn't being unsafe sufficient to sync with suspend requests? ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Sat Apr 10 13:59:38 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 10 Apr 2021 13:59:38 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: <-fsVAozVnQsZHcO1hEhjJi9oALuXdOCOg7q6wqgyvaA=.b0e4face-f58b-45ae-83ba-c6b249752272@github.com> References: <-fsVAozVnQsZHcO1hEhjJi9oALuXdOCOg7q6wqgyvaA=.b0e4face-f58b-45ae-83ba-c6b249752272@github.com> Message-ID: On Sat, 10 Apr 2021 07:38:37 GMT, Richard Reingruber wrote: >> `HandshakeState::suspend()` is a synchronous handshake and adding the >> handshake to the queue is lock free, but the execution of the synchronous >> handshake itself requires a `HandshakeState::claim_handshake()` call which >> does acquire the lock in question. We (the suspend requester) hold the lock >> while the handshake is being processed so we either detect that >> _handshakee->set_exiting() won the race (in the target thread) or we (the >> suspend requester) win the race of setting the suspend flag so the target >> thread can't exit yet. >> >> Hopefully that helps explain this dance. > > Hi Dan, > > thanks for picking up my question! > >> `HandshakeState::suspend()` is a synchronous handshake and adding the >> handshake to the queue is lock free, but the execution of the synchronous >> handshake itself requires a `HandshakeState::claim_handshake()` call which >> does acquire the lock in question. > > My point would be that the attempt to execute the synchronous handshake for > suspending a thread that is just about to call HandshakeState::thread_exit() > cannot make progress (blocks) while the target thread is not safe > (_thread_in_vm). > > A synchronous handshake requires the target thread to be in a safe state for the > requester to execute the handshake operation. When executing > HandshakeState::thread_exit() the suspendee is _thread_in_vm. And the requester > will find it to be `_not_safe` when calling `possibly_can_process_handshake()` > before calling `HandshakeState::claim_handshake()` or when calling > `can_process_handshake()` afterwards. In both cases try_process() returns with > failure _not_safe and the lock is not held. > > ++ > 546 if (!possibly_can_process_handshake()) { > 547 // JT is observed in an unsafe state, it must notice the handshake itself > 548 return HandshakeState::_not_safe; > 549 } > 550 > 551 // Claim the mutex if there still an operation to be executed. > 552 if (!claim_handshake()) { > 553 return HandshakeState::_claim_failed; > 554 } > 555 > 556 // If we own the mutex at this point and while owning the mutex we > 557 // can observe a safe state the thread cannot possibly continue without > 558 // getting caught by the mutex. > 559 if (!can_process_handshake()) { > 560 _lock.unlock(); > 561 return HandshakeState::_not_safe; > 562 } > > So isn't being unsafe sufficient to sync with suspend requests? Interesting point that I didn't pick up from your previous comment. Thanks for making it more clear for me. I need to mull on it for a bit. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 06:50:21 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 06:50:21 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: <-fsVAozVnQsZHcO1hEhjJi9oALuXdOCOg7q6wqgyvaA=.b0e4face-f58b-45ae-83ba-c6b249752272@github.com> Message-ID: On Sat, 10 Apr 2021 13:56:41 GMT, Daniel D. Daugherty wrote: >> Hi Dan, >> >> thanks for picking up my question! >> >>> `HandshakeState::suspend()` is a synchronous handshake and adding the >>> handshake to the queue is lock free, but the execution of the synchronous >>> handshake itself requires a `HandshakeState::claim_handshake()` call which >>> does acquire the lock in question. >> >> My point would be that the attempt to execute the synchronous handshake for >> suspending a thread that is just about to call HandshakeState::thread_exit() >> cannot make progress (blocks) while the target thread is not safe >> (_thread_in_vm). >> >> A synchronous handshake requires the target thread to be in a safe state for the >> requester to execute the handshake operation. When executing >> HandshakeState::thread_exit() the suspendee is _thread_in_vm. And the requester >> will find it to be `_not_safe` when calling `possibly_can_process_handshake()` >> before calling `HandshakeState::claim_handshake()` or when calling >> `can_process_handshake()` afterwards. In both cases try_process() returns with >> failure _not_safe and the lock is not held. >> >> ++ >> 546 if (!possibly_can_process_handshake()) { >> 547 // JT is observed in an unsafe state, it must notice the handshake itself >> 548 return HandshakeState::_not_safe; >> 549 } >> 550 >> 551 // Claim the mutex if there still an operation to be executed. >> 552 if (!claim_handshake()) { >> 553 return HandshakeState::_claim_failed; >> 554 } >> 555 >> 556 // If we own the mutex at this point and while owning the mutex we >> 557 // can observe a safe state the thread cannot possibly continue without >> 558 // getting caught by the mutex. >> 559 if (!can_process_handshake()) { >> 560 _lock.unlock(); >> 561 return HandshakeState::_not_safe; >> 562 } >> >> So isn't being unsafe sufficient to sync with suspend requests? > > Interesting point that I didn't pick up from your previous comment. > Thanks for making it more clear for me. I need to mull on it for a bit. Technically you are correct. I have tested to remove this is previously version and all tests passes fine. The reason I kept it is because the suspender have identified a thread for suspension and deemed it suspendable, so we play nice. To know why suspend failed the suspender must check if thread is exiting after a failed suspend. (originally I had a bug here which caused me to wrongfully introduce this from the beginning) I'll remove it, since it simplifies the code and David's comments about this code is now out-of-line can be fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 07:12:43 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 07:12:43 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> References: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> Message-ID: On Fri, 9 Apr 2021 16:16:45 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 six commits: >> >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > I'm still really happy with this fix! Thumbs up! > Reminder: don't forget to decide what to do about the obsolete options. > @dholmes-ora can provide guidance on how to handle this type of removal. Thanks Serguei, Fixed nits. > I wonder why ThreadSuspensionHandshake is not stack allocated as SuspendThreadHandshake below: Simplified: Suspender thread target another thread for suspension. It first allocates the synchronous handshake on stack and tries to execute it. When the target thread becomes blocked/native we install the asynchronous handshake (the trap). The trap will stop the target thread from leaving blocked/native until we resume it. Since the suspender now have successfully suspended the target (the trap is installed) it will return from this method call. Thus it's stack is not usable for the asynchronous handshake. The trap can even be executed after the suspender thread have terminated, therefore we need to but the trap on the heap. Hope this answers your question! Thanks, Robbin > Thanks, > Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 07:34:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 07:34:19 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> Message-ID: On Fri, 9 Apr 2021 17:23:36 GMT, Serguei Spitsyn wrote: >> I'm not fond of `self_suspended` as the function name. >> Perhaps `do_self_suspend` or something like that... >> (What color would you like that bike shed?) > > I like the suggestion to rename self_suspened to do_self_suspend. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 07:47:07 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 07:47:07 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> References: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> Message-ID: <82CqXQRu4OD8i9KFwuUswnYTHFaqktISMYKAsIt7A9k=.4208365c-9aa1-4cd2-aff9-89d14d239ecc@github.com> On Fri, 9 Apr 2021 15:34:50 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 six commits: >> >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.hpp line 131: > >> 129: return true; >> 130: } >> 131: OrderAccess::loadload(); > > Needs a comment explaining what the memory sync is for. Fixed > src/hotspot/share/runtime/handshake.hpp line 156: > >> 154: // This flag is true while there is async handshake (trap) >> 155: // on queue. Since we do only need one, we can reuse it if >> 156: // thread thread gets suspended again (after a resume) > > typo: s/thread thread/thread/ Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 08:03:32 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 08:03:32 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> References: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> Message-ID: On Fri, 9 Apr 2021 16:16:45 GMT, Daniel D. Daugherty wrote: > I'm still really happy with this fix! Thumbs up! > Reminder: don't forget to decide what to do about the obsolete options. > @dholmes-ora can provide guidance on how to handle this type of removal. Thanks, yes fixing CSR! > src/hotspot/share/runtime/handshake.cpp line 654: > >> 652: void do_thread(Thread* thr) { >> 653: JavaThread* target = thr->as_Java_thread(); >> 654: target->handshake_state()->self_suspened(); > > Typo: s/self_suspened/self_suspended/ Fixed > src/hotspot/share/runtime/objectMonitor.cpp line 970: > >> 968: >> 969: current->frame_anchor()->make_walkable(current); >> 970: OrderAccess::storestore(); > > Needs a comment explaining what the memory sync is for. Fixed > src/hotspot/share/runtime/objectMonitor.cpp line 977: > >> 975: if (_succ == current) { >> 976: _succ = NULL; >> 977: OrderAccess::fence(); > > Please add a comment to this line: > `OrderAccess::fence(); // always do a full fence when successor is cleared` Fixed > src/hotspot/share/runtime/objectMonitor.cpp line 1540: > >> 1538: { >> 1539: current->frame_anchor()->make_walkable(current); >> 1540: OrderAccess::storestore(); > > Needs a comment explaining what the memory sync is for. Fixed > src/hotspot/share/runtime/objectMonitor.cpp line 1555: > >> 1553: if (_succ == current) { >> 1554: _succ = NULL; >> 1555: OrderAccess::fence(); > > Please add a comment to this line: > OrderAccess::fence(); // always do a full fence when successor is cleared Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rrich at openjdk.java.net Mon Apr 12 08:03:30 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 12 Apr 2021 08:03:30 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 07:17:48 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - White space fixes > - Merge branch 'master' into SuspendInHandshake > - Review fixes > - Merge branch 'master' into SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - 8257831: Suspend with handshake (review baseline) Nice ?? Richard. ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 08:03:32 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 08:03:32 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: <-fsVAozVnQsZHcO1hEhjJi9oALuXdOCOg7q6wqgyvaA=.b0e4face-f58b-45ae-83ba-c6b249752272@github.com> Message-ID: On Mon, 12 Apr 2021 07:44:38 GMT, Richard Reingruber wrote: > Also it does not eliminate the race as far as I can tell. You are correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rrich at openjdk.java.net Mon Apr 12 08:03:32 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 12 Apr 2021 08:03:32 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: <-fsVAozVnQsZHcO1hEhjJi9oALuXdOCOg7q6wqgyvaA=.b0e4face-f58b-45ae-83ba-c6b249752272@github.com> Message-ID: On Mon, 12 Apr 2021 06:42:47 GMT, Robbin Ehn wrote: > > > Technically you are correct. > I have tested to remove this is previously version and all tests passes fine. > The reason I kept it is because the suspender have identified a thread for suspension and deemed it suspendable, so we play nice. > To know why suspend failed the suspender must check if thread is exiting after a failed suspend. (originally I had a bug here which caused me to wrongfully introduce this from the beginning) Thanks for the explanation. As I understand you want to be fault tolerant towards somewhat sloppy agents. That's of course ok. It should be explained in a comment though. > I'll remove it, since it simplifies the code and David's comments about this code is now out-of-line can be fixed. Also it does not eliminate the race as far as I can tell. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 08:09:28 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 08:09:28 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 07:56:36 GMT, Richard Reingruber wrote: > Nice > Richard. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 08:09:29 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 08:09:29 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 03:24:45 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/thread.cpp line 667: >> >>> 665: >>> 666: // We wait for the thread to transition to a more usable state. >>> 667: for (int i = 1; i <= SuspendRetryCount; i++) { >> >> You will need to obsolete SuspendRetryCount and SuspendRetryDelay. This will need a CSR request indicating why there is no deprecation step. > > I think we will need to do the same for flags AssertOnSuspendWaitFailure and TraceSuspendWaitFailures. I'll create CSR for the related to this change-set flags, SuspendRetryCount and SuspendRetryDelay. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 10:38:25 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 10:38:25 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 12:57:01 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/handshake.cpp line 677: >> >>> 675: } else { >>> 676: // Target is going to wake up and leave suspension. >>> 677: // Let's just stop the thread from doing that. >> >> IIUC this would be the case where the target was hit with a suspend request but has not yet processed the actual suspension handshake op, then a resume comes in so suspended is no longer true, and then another suspend request is made (this one) which simply turns the suspended flag back on - is that right? >> Overall I'm finding it very hard to see what the two suspend state flags actually signify. I'd like to see that written up somewhere. > > Sure I pushed some changes with some more comments and renamed the flag. I hope that help, if not, let me know. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 10:38:24 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 10:38:24 GMT Subject: RFR: 8257831: Suspend with handshakes [v5] In-Reply-To: References: Message-ID: <5lV-lT_joH_rjVXRphghGWLew_Cl7FfYbDh6xi4qXP4=.33c4a7ff-5038-4027-aded-19e185f738fe@github.com> > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Review fixes 2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3191/files - new: https://git.openjdk.java.net/jdk/pull/3191/files/ed8accf0..7e704326 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=03-04 Stats: 51 lines in 4 files changed: 18 ins; 24 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191 PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 10:53:46 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 10:53:46 GMT Subject: RFR: 8257831: Suspend with handshakes [v6] In-Reply-To: References: Message-ID: > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into SuspendInHandshake - Review fixes 2 - White space fixes - Merge branch 'master' into SuspendInHandshake - Review fixes - Merge branch 'master' into SuspendInHandshake - Merge branch 'master' into SuspendInHandshake - 8257831: Suspend with handshake (review baseline) ------------- Changes: https://git.openjdk.java.net/jdk/pull/3191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=05 Stats: 1332 lines in 39 files changed: 273 ins; 863 del; 196 mod Patch: https://git.openjdk.java.net/jdk/pull/3191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191 PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 10:53:47 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 10:53:47 GMT Subject: RFR: 8257831: Suspend with handshakes [v6] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 13:57:50 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/thread.inline.hpp line 207: >> >>> 205: } >>> 206: >>> 207: inline void JavaThread::set_terminated(TerminatedTypes t) { >> >> I prefer set_terminated(arg) over the new set of methods. > > We had two methods: > > void set_terminated(TerminatedTypes t); > void set_terminated_value(); > > Terminated is part of the name of the method, the name of the flag, the name of the type and part of the names of two of the states, which is very confusing. > > Also the setters now match the queries: > E.g. > `bool is_exiting()` > > The queries do not indicate in any sense that they are queries on the terminated flag. > The state flag is an implementation detail from query POV. > So to be consistent e.g. "set_exiting()" also hides the fact that we keep track of this with a flag. Please advise :) , I can roll back if you insist! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 12 10:53:46 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Apr 2021 10:53:46 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> Message-ID: On Mon, 12 Apr 2021 07:57:14 GMT, Robbin Ehn wrote: > I'm still really happy with this fix! Thumbs up! > Reminder: don't forget to decide what to do about the obsolete options. > @dholmes-ora can provide guidance on how to handle this type of removal. Thanks, yes I'll start a CSR! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From david.holmes at oracle.com Mon Apr 12 13:09:31 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Apr 2021 23:09:31 +1000 Subject: RFR: 8257831: Suspend with handshakes [v6] In-Reply-To: References: Message-ID: On 12/04/2021 8:53 pm, Robbin Ehn wrote: > On Wed, 7 Apr 2021 13:57:50 GMT, Robbin Ehn wrote: > >>> src/hotspot/share/runtime/thread.inline.hpp line 207: >>> >>>> 205: } >>>> 206: >>>> 207: inline void JavaThread::set_terminated(TerminatedTypes t) { >>> >>> I prefer set_terminated(arg) over the new set of methods. >> >> We had two methods: >> >> void set_terminated(TerminatedTypes t); >> void set_terminated_value(); >> >> Terminated is part of the name of the method, the name of the flag, the name of the type and part of the names of two of the states, which is very confusing. I'll admit the API is not that clean but I would expect the method, the flag, the type, to all share a common name as they are all related to the same underlying thing: the termination state. set_terminated_value() seems completely unnecessary as a special-case. >> >> Also the setters now match the queries: >> E.g. >> `bool is_exiting()` >> >> The queries do not indicate in any sense that they are queries on the terminated flag. >> The state flag is an implementation detail from query POV. >> So to be consistent e.g. "set_exiting()" also hides the fact that we keep track of this with a flag. The point of the flag is that it is tracking a singular termination state with a progression from _not_terminated, through _thread_exiting, to _thread terminated, or the special state _vm_terminated (though I'm not sure why we need that ...) > Please advise :) , I can roll back if you insist! There is always room for improvement with these things, but the changes you are making to this part of the thread API seem completely unrelated to thread suspension, so I'd ask that you please roll them back, for now at least. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3191 > From dcubed at openjdk.java.net Mon Apr 12 16:11:01 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 12 Apr 2021 16:11:01 GMT Subject: RFR: 8265082: test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java fails validate-source Message-ID: A trivial fix to fix the "validate-source" failure in Tier1 due to the bad copyright header in test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java. ------------- Commit messages: - 8265082: test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java fails validate-source Changes: https://git.openjdk.java.net/jdk/pull/3438/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3438&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265082 Stats: 8 lines in 1 file changed: 4 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3438.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3438/head:pull/3438 PR: https://git.openjdk.java.net/jdk/pull/3438 From mikael at openjdk.java.net Mon Apr 12 16:11:01 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 12 Apr 2021 16:11:01 GMT Subject: RFR: 8265082: test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java fails validate-source In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 16:03:24 GMT, Daniel D. Daugherty wrote: > A trivial fix to fix the "validate-source" failure in Tier1 due to the bad copyright > header in test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3438 From erikj at openjdk.java.net Mon Apr 12 16:11:01 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 12 Apr 2021 16:11:01 GMT Subject: RFR: 8265082: test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java fails validate-source In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 16:03:24 GMT, Daniel D. Daugherty wrote: > A trivial fix to fix the "validate-source" failure in Tier1 due to the bad copyright > header in test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3438 From dcubed at openjdk.java.net Mon Apr 12 16:17:47 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 12 Apr 2021 16:17:47 GMT Subject: RFR: 8265082: test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java fails validate-source In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 16:06:00 GMT, Mikael Vidstedt wrote: >> A trivial fix to fix the "validate-source" failure in Tier1 due to the bad copyright >> header in test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java. > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3438 From dcubed at openjdk.java.net Mon Apr 12 16:17:47 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 12 Apr 2021 16:17:47 GMT Subject: Integrated: 8265082: test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java fails validate-source In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 16:03:24 GMT, Daniel D. Daugherty wrote: > A trivial fix to fix the "validate-source" failure in Tier1 due to the bad copyright > header in test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java. This pull request has now been integrated. Changeset: f4794378 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/f4794378 Stats: 8 lines in 1 file changed: 4 ins; 2 del; 2 mod 8265082: test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java fails validate-source Reviewed-by: mikael, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3438 From dcubed at openjdk.java.net Mon Apr 12 16:25:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 12 Apr 2021 16:25:34 GMT Subject: RFR: 8265082: test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java fails validate-source In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 16:06:34 GMT, Erik Joelsson wrote: >> A trivial fix to fix the "validate-source" failure in Tier1 due to the bad copyright >> header in test/hotspot/jtreg/gc/g1/TestG1SkipCompaction.java. > > Marked as reviewed by erikj (Reviewer). @erikj79 - Thanks for your review also. ------------- PR: https://git.openjdk.java.net/jdk/pull/3438 From pchilanomate at openjdk.java.net Mon Apr 12 16:28:01 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 12 Apr 2021 16:28:01 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() Message-ID: Hi, Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/3436/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3436&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265035 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3436.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3436/head:pull/3436 PR: https://git.openjdk.java.net/jdk/pull/3436 From iklam at openjdk.java.net Mon Apr 12 16:52:33 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 12 Apr 2021 16:52:33 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v4] In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> References: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> Message-ID: <5dhg50Ktvcm23PgJR3WejtOxkozTDxNLjAn07pMzPAY=.7d29d3d1-8a14-403f-9cbe-acd1bfe05e11@github.com> On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes wrote: >> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". >> >> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. >> >> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. >> >> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). >> >> Some missing CHECK_ uses were added. >> >> Testing: >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix search&replace mistake LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3394 From hseigel at openjdk.java.net Mon Apr 12 17:13:33 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 12 Apr 2021 17:13:33 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. > The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. > > Thanks, > Patricio The changes look good. Were regression tests run? Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3436 From pchilanomate at openjdk.java.net Mon Apr 12 17:48:50 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 12 Apr 2021 17:48:50 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 17:11:11 GMT, Harold Seigel wrote: > The changes look good. Were regression tests run? > Thanks, Harold Thanks Harold! Yes, I run tiers 1-3 in mach5. ------------- PR: https://git.openjdk.java.net/jdk/pull/3436 From dcubed at openjdk.java.net Mon Apr 12 21:02:49 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 12 Apr 2021 21:02:49 GMT Subject: RFR: 8257831: Suspend with handshakes [v6] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 10:53:46 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into SuspendInHandshake > - Review fixes 2 > - White space fixes > - Merge branch 'master' into SuspendInHandshake > - Review fixes > - Merge branch 'master' into SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - 8257831: Suspend with handshake (review baseline) I only found nits so still looks good to me. src/hotspot/share/runtime/handshake.cpp line 466: > 464: // The exception to this rule is the asynchronous suspension handshake. > 465: // It by-passes the NSV by manully doing the transition. > 466: // Since we can have safepoints while suspeneded we need to release the tty locker if it is held. nit typo: s/manully/manually/ nit typo: s/suspeneded/suspended/ src/hotspot/share/runtime/handshake.hpp line 133: > 131: // check the _lock, if held go to slow path. > 132: // Since the handshakee is unsafe if _lock gets lock after this check > 133: // we know another threads cannot process any handshakes. nit typo: s/_lock gets lock/_lock gets locked/ nit typo: s/threads/thread/ src/hotspot/share/runtime/thread.cpp line 1448: > 1446: // The careful dance between thread suspension and exit is handled here. > 1447: // Since we are in vm and suspension is done with handshakes, > 1448: // we can just put in the exiting state and it will be corrcetly handled. Perhaps: s/Since we are in vm and/Since we are in thread_in_vm state and/ nit typo: s/corrcetly/correctly/ ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From dholmes at openjdk.java.net Mon Apr 12 21:55:58 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Apr 2021 21:55:58 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v2] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 13:00:03 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed CHECK on return statement. > > I think substituting "JavaThread* thread" for "JavaThread* current" is a good change and convention that makes the code more clear, so worth the dull code review and diffs. Thanks for the reviews @coleenp , @hseigel and @iklam . Can someone from compiler team please take a look and give the okay? (I know things are a bit busy at the moment.) Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3394 From dholmes at openjdk.java.net Mon Apr 12 22:03:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Apr 2021 22:03:05 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. > The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. > > Thanks, > Patricio Hi Patricio, Changes look good. Though I wonder whether we even need the EXCEPTION_MARK? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3436 From dholmes at openjdk.java.net Mon Apr 12 23:43:01 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Apr 2021 23:43:01 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Thu, 8 Apr 2021 04:40:05 GMT, David Holmes wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> add throw exception > > src/hotspot/share/classfile/systemDictionary.cpp line 1939: > >> 1937: ResolutionErrorEntry* entry = resolution_errors()->find_entry(index, hash, pool, which); >> 1938: if (entry != NULL && entry->nest_host_error() == NULL) { >> 1939: entry->set_nest_host_error(message); > > You should never find an entry where the nest_host_error() is NULL. If there were such an entry then it implies a regular resolution error occurred, but that means we cannot have reached this code as `klass_at` in our caller would have thrown the exception. So this should simply be: > if (entry != NULL) { > assert(entry->nest_host_error() != NULL, "cannot have a NULL error at this point"); > } > You also need to delete part of the method comment: > //... If an entry already exists it will > // be updated with the nest host error message. > as we don't do that. Sorry the above is not correct. I believe the code you have is correct. I will double-check some details then update my review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From dholmes at openjdk.java.net Mon Apr 12 23:55:58 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Apr 2021 23:55:58 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Thu, 8 Apr 2021 04:38:37 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. The other whole bigger big will be fixed in the other issue. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > add throw exception I think the code you have is correct. I've suggested some additional commentary. There are a couple of races possible here, but I think the remaining ones are benign and we do not need to try and impose any stricter synchronization. Thanks, David src/hotspot/share/classfile/systemDictionary.cpp line 1939: > 1937: ResolutionErrorEntry* entry = resolution_errors()->find_entry(index, hash, pool, which); > 1938: if (entry != NULL && entry->nest_host_error() == NULL) { > 1939: entry->set_nest_host_error(message); Please add a comment before line 1939: // An existing entry means we had a true resolution failure (LinkageError) with our nest host, but we // still want to add the error message for the higher-level access checks to report. We should // only reach here under the same error condition, so we can ignore the potential race with setting // the message. If we see it is already set then we can ignore it. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3392 From pchilanomate at openjdk.java.net Tue Apr 13 01:55:56 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Apr 2021 01:55:56 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() In-Reply-To: References: Message-ID: <8UISVd6cSB_IyOK-Ssz0sRq9BcREAwLqcOV2cFiWfwA=.fcbdf0b2-56ef-4431-980f-ae2f6b375632@github.com> On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. > The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. > > Thanks, > Patricio Hi David, Thanks for looking at this. > Changes look good. > > Though I wonder whether we even need the EXCEPTION_MARK? I think it can be removed actually. The alternative could be to change it for assert(!HAS_PENDING_EXCEPTION, "there should be no pending exceptions") to only verify that there are no pending exceptions when entering refill_ic_stubs(). But I think that only makes sense if the following code can throw exceptions and you want to avoid overriding a possibly already pending one. So if you are okay too I can remove it. Thanks, Patricio > Thanks, > David ------------- PR: https://git.openjdk.java.net/jdk/pull/3436 From david.holmes at oracle.com Tue Apr 13 02:06:28 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Apr 2021 12:06:28 +1000 Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() In-Reply-To: <8UISVd6cSB_IyOK-Ssz0sRq9BcREAwLqcOV2cFiWfwA=.fcbdf0b2-56ef-4431-980f-ae2f6b375632@github.com> References: <8UISVd6cSB_IyOK-Ssz0sRq9BcREAwLqcOV2cFiWfwA=.fcbdf0b2-56ef-4431-980f-ae2f6b375632@github.com> Message-ID: <3230b478-6f53-140f-e8f4-d9de3bd4b70b@oracle.com> On 13/04/2021 11:55 am, Patricio Chilano Mateo wrote: > On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo wrote: > >> Hi, >> >> Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. >> The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. You also need to manifest THREAD to use HAS_PENDING_EXCEPTION. I suspect the EM was introduced purely to make THREAD available for the code you've removed. I have no concerns with removing the EM if you want to. Thanks, David >> >> Thanks, >> Patricio > > Hi David, > > Thanks for looking at this. > >> Changes look good. >> >> Though I wonder whether we even need the EXCEPTION_MARK? > > I think it can be removed actually. The alternative could be to change it for assert(!HAS_PENDING_EXCEPTION, "there should be no pending exceptions") to only verify that there are no pending exceptions when entering refill_ic_stubs(). But I think that only makes sense if the following code can throw exceptions and you want to avoid overriding a possibly already pending one. So if you are okay too I can remove it. > > Thanks, > Patricio >> Thanks, >> David > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3436 > From dholmes at openjdk.java.net Tue Apr 13 02:28:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Apr 2021 02:28:18 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 07:20:15 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 428: >> >>> 426: jt->set_thread_state_fence(_thread_in_native_trans); >>> 427: SafepointMechanism::process_if_requested(jt); >>> 428: if (jt->is_interrupted(true)) { >> >> A thread must be _thread_in_vm to safely query is_interrupted() as it accesses the threadObj. > > Any unsafe (not native/blocked) is fine, therefore I never completed the transition. > I set the state to _thread_in_vm before. Sorry I was misremembering the restriction, please remove the transition to _thread_in_vm again (it messes up the comments at lines 436 and 437.) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From pchilanomate at openjdk.java.net Tue Apr 13 02:29:17 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Apr 2021 02:29:17 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() [v2] In-Reply-To: References: Message-ID: > Hi, > > Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. > The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Remove EXCEPTION_MARK ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3436/files - new: https://git.openjdk.java.net/jdk/pull/3436/files/76dbae73..c2f3fdf0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3436&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3436&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3436.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3436/head:pull/3436 PR: https://git.openjdk.java.net/jdk/pull/3436 From pchilanomate at openjdk.java.net Tue Apr 13 02:33:55 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Apr 2021 02:33:55 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() In-Reply-To: <3230b478-6f53-140f-e8f4-d9de3bd4b70b@oracle.com> References: <3230b478-6f53-140f-e8f4-d9de3bd4b70b@oracle.com> Message-ID: <3zdO1zTW8FEZnEG5WJhHQIqvSm6D6QKMCJSx00WKq8Y=.97625ef5-572a-4329-87a7-883ff5116f37@github.com> On Tue, 13 Apr 2021 02:08:00 GMT, David Holmes wrote: > On 13/04/2021 11:55 am, Patricio Chilano Mateo wrote: > > > On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo wrote: > > > Hi, > > > Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. > > > The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. > > You also need to manifest THREAD to use HAS_PENDING_EXCEPTION. I suspect > the EM was introduced purely to make THREAD available for the code > you've removed. > > I have no concerns with removing the EM if you want to. Ok, I removed the EM. Thanks! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3436 From dholmes at openjdk.java.net Tue Apr 13 02:45:16 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Apr 2021 02:45:16 GMT Subject: RFR: 8257831: Suspend with handshakes [v6] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 10:53:46 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into SuspendInHandshake > - Review fixes 2 > - White space fixes > - Merge branch 'master' into SuspendInHandshake > - Review fixes > - Merge branch 'master' into SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - 8257831: Suspend with handshake (review baseline) src/hotspot/share/runtime/objectMonitor.cpp line 447: > 445: // Completed the tranisition. > 446: SafepointMechanism::process_if_requested(current); > 447: current->set_thread_state(_thread_in_vm); I feel very uncomfortable that we remain _thread_blocked_trans across such a lengthy chunk of code - particularly the call to exit()! This is an abuse of the trans states which are only supposed to exist and be used to ensure the correctness of the Dekker-duality when setting and reading the thread state. And I still would prefer to see these state changes and related safepoint-mechanism checks encapsulated somehow. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dholmes at openjdk.java.net Tue Apr 13 02:50:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Apr 2021 02:50:18 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> References: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> Message-ID: On Fri, 9 Apr 2021 15:45:50 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 six commits: >> >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/thread.cpp line 455: > >> 453: ParkEvent::Release(_ParkEvent); >> 454: // Can be racingly loaded in signal handler via has_terminated() >> 455: Atomic::store(&_ParkEvent, (ParkEvent*)NULL); > > Nice solution for that odd signal handler issue. Yes nice simple fix, but note that the comments at lines 451 and 452 are wrong - we can't ever encounter a null _ParkEvent, and we are not nulling for good hygiene any more. I suggest the comment at line 454 be changed to read: // Set to NULL as a termination indicator for has_terminated(). ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dholmes at openjdk.java.net Tue Apr 13 02:54:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Apr 2021 02:54:18 GMT Subject: RFR: 8257831: Suspend with handshakes [v6] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 10:53:46 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into SuspendInHandshake > - Review fixes 2 > - White space fixes > - Merge branch 'master' into SuspendInHandshake > - Review fixes > - Merge branch 'master' into SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - 8257831: Suspend with handshake (review baseline) src/hotspot/share/runtime/thread.hpp line 746: > 744: > 745: // _ParkEvent is cleared > 746: bool has_terminated() { return Atomic::load(&_ParkEvent) == NULL; }; Please change the comment to: // Termination indicator used by the signal handler. _ParkEvent is just a convenient field // we can NULL out after setting the JavaThread termination state (which can't itself be read // from the signal handler if a signal hits during the Thread destructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dholmes at openjdk.java.net Tue Apr 13 04:10:58 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Apr 2021 04:10:58 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() [v2] In-Reply-To: References: Message-ID: <9Cj8MYPFQmzoBHsaW6B5NX72vfrNF3r68FGinn1yHts=.cb93c4d9-258e-4454-b86b-a4b69d1fb2e0@github.com> On Tue, 13 Apr 2021 02:29:17 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. >> The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Remove EXCEPTION_MARK LGTM! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3436 From pchilanomate at openjdk.java.net Tue Apr 13 04:10:58 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Apr 2021 04:10:58 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() In-Reply-To: <3230b478-6f53-140f-e8f4-d9de3bd4b70b@oracle.com> References: <3230b478-6f53-140f-e8f4-d9de3bd4b70b@oracle.com> Message-ID: <3zdO1zTW8FEZnEG5WJhHQIqvSm6D6QKMCJSx00WKq8Y=.1244f209-b60c-4676-8fc2-90602dd2a36b@github.com> On Tue, 13 Apr 2021 02:08:00 GMT, David Holmes wrote: > On 13/04/2021 11:55 am, Patricio Chilano Mateo wrote: > > > On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo wrote: > > > Hi, > > > Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. > > > The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. > > You also need to manifest THREAD to use HAS_PENDING_EXCEPTION. I suspect > the EM was introduced purely to make THREAD available for the code > you've removed. > > I have no concerns with removing the EM if you want to. Ok, I removed the EM. Thanks! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3436 From pchilanomate at openjdk.java.net Tue Apr 13 04:11:57 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Apr 2021 04:11:57 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() In-Reply-To: <3230b478-6f53-140f-e8f4-d9de3bd4b70b@oracle.com> References: <3230b478-6f53-140f-e8f4-d9de3bd4b70b@oracle.com> Message-ID: <3zdO1zTW8FEZnEG5WJhHQIqvSm6D6QKMCJSx00WKq8Y=.c40742c1-4eb9-479d-ad44-8145febdaba0@github.com> On Tue, 13 Apr 2021 02:08:00 GMT, David Holmes wrote: > On 13/04/2021 11:55 am, Patricio Chilano Mateo wrote: > > > On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo wrote: > > > Hi, > > > Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. > > > The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. > > You also need to manifest THREAD to use HAS_PENDING_EXCEPTION. I suspect > the EM was introduced purely to make THREAD available for the code > you've removed. > > I have no concerns with removing the EM if you want to. Ok, I removed the EM. Thanks! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3436 From rehn at openjdk.java.net Tue Apr 13 06:58:12 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 06:58:12 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: <8XHYnrIhSOcB6qEpq4-1FlTw8LvfPTmIG3LyIs3BC8E=.301d2dff-0341-44e3-b066-e80b3945a9a6@github.com> Message-ID: On Thu, 8 Apr 2021 08:12:11 GMT, Serguei Spitsyn wrote: > The functions JvmtiSuspendControl::suspend and JvmtiSuspendControl::resume are not really needed anymore. You probably decided to keep them around to simplify merges a little bit. Is that right? There is also the debug printing method, which I did not know were to place. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From mikael at openjdk.java.net Tue Apr 13 07:10:06 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 13 Apr 2021 07:10:06 GMT Subject: RFR: 8265112: ProblemList some java/foreign tests on macosx-aarch64 Message-ID: Let's problem list java/foreign/{StdLibTest,TestVarArgs,valist/VaListTest}.java (all tier1 tests) until JDK-8263512 is fixed. ------------- Commit messages: - 8265112: ProblemList some java/foreign tests on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3451/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3451&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265112 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3451.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3451/head:pull/3451 PR: https://git.openjdk.java.net/jdk/pull/3451 From mikael at openjdk.java.net Tue Apr 13 07:10:12 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 13 Apr 2021 07:10:12 GMT Subject: RFR: 8265110: ProblemList compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java on macosx-aarch64 Message-ID: Let's problem list compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java (a tier1 test) until JDK-8262901 is fixed. ------------- Commit messages: - 8265110: ProblemList compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3450/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3450&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265110 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3450.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3450/head:pull/3450 PR: https://git.openjdk.java.net/jdk/pull/3450 From mikael at openjdk.java.net Tue Apr 13 07:11:13 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 13 Apr 2021 07:11:13 GMT Subject: RFR: 8265113: ProblemList gtest/GTestWrapper.java:os.release_multi_mappings on macosx-aarch64 Message-ID: Let's do the equivalent of problem listing the gtest/GTestWrapper.java os.release_multi_mappings sub-test (included in tier1) until JDK-8262952 is fixed. Note: I considered a few different ways of disabling the test on macosx-aarch64. The gtest docs (https://github.com/google/googletest/blob/master/docs/advanced.md#temporarily-disabling-tests) note, and I agree, that adding the DISABLED_ prefix is preferable over preprocessor excluding the whole test. There are several ways to add the DISABLED_ prefix conditionally, only on macosx-aarch64. In the end I found this the easiest to read and understand. ------------- Commit messages: - 8265113: ProblemList gtest/GTestWrapper.java:os.release_multi_mappings on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3454/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3454&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265113 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3454.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3454/head:pull/3454 PR: https://git.openjdk.java.net/jdk/pull/3454 From mikael at openjdk.java.net Tue Apr 13 07:12:07 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 13 Apr 2021 07:12:07 GMT Subject: RFR: 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64 Message-ID: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com> Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a tier1 test) until JDK-8262897 is fixed. ------------- Commit messages: - 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3452/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3452&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265111 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3452.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3452/head:pull/3452 PR: https://git.openjdk.java.net/jdk/pull/3452 From rehn at openjdk.java.net Tue Apr 13 07:15:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 07:15:19 GMT Subject: RFR: 8257831: Suspend with handshakes [v6] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 20:51:17 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 eight commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes 2 >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.cpp line 466: > >> 464: // The exception to this rule is the asynchronous suspension handshake. >> 465: // It by-passes the NSV by manully doing the transition. >> 466: // Since we can have safepoints while suspeneded we need to release the tty locker if it is held. > > nit typo: s/manully/manually/ > nit typo: s/suspeneded/suspended/ Fixed > src/hotspot/share/runtime/handshake.hpp line 133: > >> 131: // check the _lock, if held go to slow path. >> 132: // Since the handshakee is unsafe if _lock gets lock after this check >> 133: // we know another threads cannot process any handshakes. > > nit typo: s/_lock gets lock/_lock gets locked/ > nit typo: s/threads/thread/ Fixed > src/hotspot/share/runtime/thread.cpp line 1448: > >> 1446: // The careful dance between thread suspension and exit is handled here. >> 1447: // Since we are in vm and suspension is done with handshakes, >> 1448: // we can just put in the exiting state and it will be corrcetly handled. > > Perhaps: s/Since we are in vm and/Since we are in thread_in_vm state and/ > nit typo: s/corrcetly/correctly/ Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 13 07:26:21 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 07:26:21 GMT Subject: RFR: 8257831: Suspend with handshakes [v6] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 02:41:41 GMT, David Holmes 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 eight commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes 2 >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/objectMonitor.cpp line 447: > >> 445: // Completed the tranisition. >> 446: SafepointMechanism::process_if_requested(current); >> 447: current->set_thread_state(_thread_in_vm); > > I feel very uncomfortable that we remain _thread_blocked_trans across such a lengthy chunk of code - particularly the call to exit()! This is an abuse of the trans states which are only supposed to exist and be used to ensure the correctness of the Dekker-duality when setting and reading the thread state. > > And I still would prefer to see these state changes and related safepoint-mechanism checks encapsulated somehow. Yes we should figure out something here. Note that we use to call exit() while blocked. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From ksakata at openjdk.java.net Tue Apr 13 07:33:05 2021 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Tue, 13 Apr 2021 07:33:05 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log Message-ID: When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. $ java -Xlog::sample.log:: Sample $ jcmd 4976 VM.log list Log output configuration: #0: stdout all=warning uptime,level,tags #1: stderr all=off uptime,level,tags #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" 4976: Output options for existing outputs are ignored. $ jcmd 4976 VM.log output="#2" output_options="filecount=100" 4976: Command executed successfully It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. $ jcmd 4976 VM.log list #0: stdout all=warning uptime,level,tags #1: stderr all=off uptime,level,tags #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) This pull request enable to show the warning message when specifying the output index. $ java -Xlog::sample.log:: Sample $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" 5054: Output options for existing outputs are ignored. $ jcmd 5054 VM.log output="#2" output_options="filecount=100" 5054: Output options for existing outputs are ignored. ### gtest result $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* Note: Google Test filter = LogConfigurationTest.* [==========] Running 15 tests from 1 test case. [----------] Global test environment set-up. [----------] 15 tests from LogConfigurationTest [ RUN ] LogConfigurationTest.describe_vm [ OK ] LogConfigurationTest.describe_vm (1 ms) [ RUN ] LogConfigurationTest.update_output_vm [ OK ] LogConfigurationTest.update_output_vm (0 ms) [ RUN ] LogConfigurationTest.add_new_output_vm [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) [ RUN ] LogConfigurationTest.disable_logging_vm [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) [ RUN ] LogConfigurationTest.disable_output_vm [ OK ] LogConfigurationTest.disable_output_vm (0 ms) [ RUN ] LogConfigurationTest.reconfigure_decorators_vm [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) [ RUN ] LogConfigurationTest.invalid_configure_options_vm [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm [0.462s][warning][logging] Ignoring excess -Xlog options: "" [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) [ RUN ] LogConfigurationTest.parse_log_arguments_vm [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) [ RUN ] LogConfigurationTest.configure_stdout_vm [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) [ RUN ] LogConfigurationTest.subscribe_vm [ OK ] LogConfigurationTest.subscribe_vm (2 ms) [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) [ RUN ] LogConfigurationTest.output_name_normalization_vm [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) [ RUN ] LogConfigurationTest.suggest_similar_selection_vm [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) [----------] 15 tests from LogConfigurationTest (658 ms total) [----------] Global test environment tear-down [==========] 15 tests from 1 test case ran. (659 ms total) [ PASSED ] 15 tests. ------------- Commit messages: - Update copyright - Show a warning whenever trying to update output options Changes: https://git.openjdk.java.net/jdk/pull/3448/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3448&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265047 Stats: 8 lines in 1 file changed: 5 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3448/head:pull/3448 PR: https://git.openjdk.java.net/jdk/pull/3448 From rehn at openjdk.java.net Tue Apr 13 07:36:20 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 07:36:20 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <1Tceht1hkeeh3E5H-JakAVgWPVhEehh2aORkLP6H0Z8=.940eeba1-3691-42e3-b4d9-1527ffb28dfd@github.com> On Tue, 13 Apr 2021 02:24:45 GMT, David Holmes wrote: >> Any unsafe (not native/blocked) is fine, therefore I never completed the transition. >> I set the state to _thread_in_vm before. > > Sorry I was misremembering the restriction, please remove the transition to _thread_in_vm again (it messes up the comments at lines 436 and 437.) Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 13 07:36:21 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 07:36:21 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> Message-ID: On Tue, 13 Apr 2021 02:46:46 GMT, David Holmes wrote: >> src/hotspot/share/runtime/thread.cpp line 455: >> >>> 453: ParkEvent::Release(_ParkEvent); >>> 454: // Can be racingly loaded in signal handler via has_terminated() >>> 455: Atomic::store(&_ParkEvent, (ParkEvent*)NULL); >> >> Nice solution for that odd signal handler issue. > > Yes nice simple fix, but note that the comments at lines 451 and 452 are wrong - we can't ever encounter a null _ParkEvent, and we are not nulling for good hygiene any more. I suggest the comment at line 454 be changed to read: > // Set to NULL as a termination indicator for has_terminated(). Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 13 07:36:23 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 07:36:23 GMT Subject: RFR: 8257831: Suspend with handshakes [v6] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 02:51:32 GMT, David Holmes 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 eight commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes 2 >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/thread.hpp line 746: > >> 744: >> 745: // _ParkEvent is cleared >> 746: bool has_terminated() { return Atomic::load(&_ParkEvent) == NULL; }; > > Please change the comment to: > > // Termination indicator used by the signal handler. _ParkEvent is just a convenient field > // we can NULL out after setting the JavaThread termination state (which can't itself be read > // from the signal handler if a signal hits during the Thread destructor. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From david.holmes at oracle.com Tue Apr 13 07:42:51 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Apr 2021 17:42:51 +1000 Subject: RFR: 8257831: Suspend with handshakes [v6] In-Reply-To: References: Message-ID: On 13/04/2021 5:26 pm, Robbin Ehn wrote: > On Tue, 13 Apr 2021 02:41:41 GMT, David Holmes 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 eight commits: >>> >>> - Merge branch 'master' into SuspendInHandshake >>> - Review fixes 2 >>> - White space fixes >>> - Merge branch 'master' into SuspendInHandshake >>> - Review fixes >>> - Merge branch 'master' into SuspendInHandshake >>> - Merge branch 'master' into SuspendInHandshake >>> - 8257831: Suspend with handshake (review baseline) >> >> src/hotspot/share/runtime/objectMonitor.cpp line 447: >> >>> 445: // Completed the tranisition. >>> 446: SafepointMechanism::process_if_requested(current); >>> 447: current->set_thread_state(_thread_in_vm); >> >> I feel very uncomfortable that we remain _thread_blocked_trans across such a lengthy chunk of code - particularly the call to exit()! This is an abuse of the trans states which are only supposed to exist and be used to ensure the correctness of the Dekker-duality when setting and reading the thread state. >> >> And I still would prefer to see these state changes and related safepoint-mechanism checks encapsulated somehow. > > Yes we should figure out something here. Could be a neat use of a lambda "on_suspension_do" ... > Note that we use to call exit() while blocked. Yes, it is the use of trans that concerns me here as very little code expects to encounter a trans-state. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3191 > From rehn at openjdk.java.net Tue Apr 13 07:56:21 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 07:56:21 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From stuefe at openjdk.java.net Tue Apr 13 09:12:02 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 13 Apr 2021 09:12:02 GMT Subject: RFR: 8265113: ProblemList gtest/GTestWrapper.java:os.release_multi_mappings on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:04:39 GMT, Mikael Vidstedt wrote: > Let's do the equivalent of problem listing the gtest/GTestWrapper.java os.release_multi_mappings sub-test (included in tier1) until JDK-8262952 is fixed. > > Note: I considered a few different ways of disabling the test on macosx-aarch64. The gtest docs (https://github.com/google/googletest/blob/master/docs/advanced.md#temporarily-disabling-tests) note, and I agree, that adding the DISABLED_ prefix is preferable over preprocessor excluding the whole test. There are several ways to add the DISABLED_ prefix conditionally, only on macosx-aarch64. In the end I found this the easiest to read and understand. LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3454 From akozlov at openjdk.java.net Tue Apr 13 11:05:02 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 13 Apr 2021 11:05:02 GMT Subject: RFR: 8265112: ProblemList some java/foreign tests on macosx-aarch64 In-Reply-To: References: Message-ID: <0KrTMTglFrIPJkxEycEUSR5J7y7saoSL0AENR9sZuJQ=.df9fb256-7026-4fa7-9ce0-8ddabf4fb49f@github.com> On Tue, 13 Apr 2021 06:53:22 GMT, Mikael Vidstedt wrote: > Let's problem list java/foreign/{StdLibTest,TestVarArgs,valist/VaListTest}.java (all tier1 tests) until JDK-8263512 is fixed. Marked as reviewed by akozlov (no project role). ------------- PR: https://git.openjdk.java.net/jdk/pull/3451 From akozlov at openjdk.java.net Tue Apr 13 11:04:59 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 13 Apr 2021 11:04:59 GMT Subject: RFR: 8265110: ProblemList compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 06:49:26 GMT, Mikael Vidstedt wrote: > Let's problem list compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java (a tier1 test) until JDK-8262901 is fixed. Marked as reviewed by akozlov (no project role). ------------- PR: https://git.openjdk.java.net/jdk/pull/3450 From akozlov at openjdk.java.net Tue Apr 13 11:06:01 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 13 Apr 2021 11:06:01 GMT Subject: RFR: 8265113: ProblemList gtest/GTestWrapper.java:os.release_multi_mappings on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:04:39 GMT, Mikael Vidstedt wrote: > Let's do the equivalent of problem listing the gtest/GTestWrapper.java os.release_multi_mappings sub-test (included in tier1) until JDK-8262952 is fixed. > > Note: I considered a few different ways of disabling the test on macosx-aarch64. The gtest docs (https://github.com/google/googletest/blob/master/docs/advanced.md#temporarily-disabling-tests) note, and I agree, that adding the DISABLED_ prefix is preferable over preprocessor excluding the whole test. There are several ways to add the DISABLED_ prefix conditionally, only on macosx-aarch64. In the end I found this the easiest to read and understand. Marked as reviewed by akozlov (no project role). ------------- PR: https://git.openjdk.java.net/jdk/pull/3454 From akozlov at openjdk.java.net Tue Apr 13 11:06:00 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 13 Apr 2021 11:06:00 GMT Subject: RFR: 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64 In-Reply-To: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com> References: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com> Message-ID: On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt wrote: > Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a tier1 test) until JDK-8262897 is fixed. Marked as reviewed by akozlov (no project role). ------------- PR: https://git.openjdk.java.net/jdk/pull/3452 From rehn at openjdk.java.net Tue Apr 13 11:57:36 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 11:57:36 GMT Subject: RFR: 8257831: Suspend with handshakes [v7] In-Reply-To: References: Message-ID: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision: - Obsolete unused flags - Review fixes 3 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3191/files - new: https://git.openjdk.java.net/jdk/pull/3191/files/6bd645c5..5034e8a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=05-06 Stats: 50 lines in 9 files changed: 6 ins; 28 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191 PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 13 11:57:36 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 11:57:36 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 13 11:58:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 11:58:19 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 13 12:07:15 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 12:07:15 GMT Subject: RFR: 8257831: Suspend with handshakes [v7] In-Reply-To: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> References: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> Message-ID: On Tue, 13 Apr 2021 11:57:36 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision: > > - Obsolete unused flags > - Review fixes 3 Update from reviews and pushed flag obsoleting. CSR: https://bugs.openjdk.java.net/browse/JDK-8265124 Running test :) @dholmes-ora the changes to set_terminated is not exactly rollback. I notice the enum was private but set_terminated was public, so I changed the enum to public and only added set_terminated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 13 12:07:14 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 12:07:14 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From hseigel at openjdk.java.net Tue Apr 13 12:45:05 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 13 Apr 2021 12:45:05 GMT Subject: RFR: 8265112: ProblemList some java/foreign tests on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 06:53:22 GMT, Mikael Vidstedt wrote: > Let's problem list java/foreign/{StdLibTest,TestVarArgs,valist/VaListTest}.java (all tier1 tests) until JDK-8263512 is fixed. LGTM and trivial. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3451 From hseigel at openjdk.java.net Tue Apr 13 12:45:07 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 13 Apr 2021 12:45:07 GMT Subject: RFR: 8265110: ProblemList compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 06:49:26 GMT, Mikael Vidstedt wrote: > Let's problem list compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java (a tier1 test) until JDK-8262901 is fixed. LGTM and trivial. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3450 From hseigel at openjdk.java.net Tue Apr 13 12:57:06 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 13 Apr 2021 12:57:06 GMT Subject: RFR: 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64 In-Reply-To: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com> References: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com> Message-ID: On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt wrote: > Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a tier1 test) until JDK-8262897 is fixed. Looks good and trivial. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3452 From hseigel at openjdk.java.net Tue Apr 13 13:23:17 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 13 Apr 2021 13:23:17 GMT Subject: RFR: 8257836: Add additional test cases to TestSyncOnValueBasedClassEvent.java Message-ID: Please review this small change to add additional test cases to TestSyncOnValueBasedClassEvent.java. The modified test was tested using Mach5 on Linux x64, Linux aarch64, Mac OS and Windows. Thanks, Harold ------------- Commit messages: - 8257836: Add additional test cases to TestSyncOnValueBasedClassEvent.java Changes: https://git.openjdk.java.net/jdk/pull/3465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3465&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257836 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3465/head:pull/3465 PR: https://git.openjdk.java.net/jdk/pull/3465 From dcubed at openjdk.java.net Tue Apr 13 14:06:01 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 13 Apr 2021 14:06:01 GMT Subject: RFR: 8265113: ProblemList gtest/GTestWrapper.java:os.release_multi_mappings on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:04:39 GMT, Mikael Vidstedt wrote: > Let's do the equivalent of problem listing the gtest/GTestWrapper.java os.release_multi_mappings sub-test (included in tier1) until JDK-8262952 is fixed. > > Note: I considered a few different ways of disabling the test on macosx-aarch64. The gtest docs (https://github.com/google/googletest/blob/master/docs/advanced.md#temporarily-disabling-tests) note, and I agree, that adding the DISABLED_ prefix is preferable over preprocessor excluding the whole test. There are several ways to add the DISABLED_ prefix conditionally, only on macosx-aarch64. In the end I found this the easiest to read and understand. I like this platform dependent technique. This is a trivial fix and does not need to wait for 24 hours. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3454 From lfoltan at openjdk.java.net Tue Apr 13 14:22:56 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Tue, 13 Apr 2021 14:22:56 GMT Subject: RFR: 8257836: Add additional test cases to TestSyncOnValueBasedClassEvent.java In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 13:15:12 GMT, Harold Seigel wrote: > Please review this small change to add additional test cases to TestSyncOnValueBasedClassEvent.java. The modified test was tested using Mach5 on Linux x64, Linux aarch64, Mac OS and Windows. > > Thanks, Harold Looks good. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3465 From mikael at openjdk.java.net Tue Apr 13 15:06:59 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 13 Apr 2021 15:06:59 GMT Subject: Integrated: 8265110: ProblemList compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 06:49:26 GMT, Mikael Vidstedt wrote: > Let's problem list compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java (a tier1 test) until JDK-8262901 is fixed. This pull request has now been integrated. Changeset: 87e39cb6 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/87e39cb6 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8265110: ProblemList compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java on macosx-aarch64 Reviewed-by: akozlov, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/3450 From mikael at openjdk.java.net Tue Apr 13 15:09:57 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 13 Apr 2021 15:09:57 GMT Subject: Integrated: 8265112: ProblemList some java/foreign tests on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 06:53:22 GMT, Mikael Vidstedt wrote: > Let's problem list java/foreign/{StdLibTest,TestVarArgs,valist/VaListTest}.java (all tier1 tests) until JDK-8263512 is fixed. This pull request has now been integrated. Changeset: a84d886f Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/a84d886f Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8265112: ProblemList some java/foreign tests on macosx-aarch64 Reviewed-by: akozlov, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/3451 From mikael at openjdk.java.net Tue Apr 13 15:11:57 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 13 Apr 2021 15:11:57 GMT Subject: Integrated: 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64 In-Reply-To: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com> References: <2LGNpnV93o_EmqfCIn-hxHxOUyZVWhZLcqwWm8oP0As=.d06ef7c3-38ea-474b-9c4f-994e81a7e933@github.com> Message-ID: On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt wrote: > Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a tier1 test) until JDK-8262897 is fixed. This pull request has now been integrated. Changeset: 2aae29c9 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/2aae29c9 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64 Reviewed-by: akozlov, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/3452 From mikael at openjdk.java.net Tue Apr 13 15:13:59 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 13 Apr 2021 15:13:59 GMT Subject: Integrated: 8265113: ProblemList gtest/GTestWrapper.java:os.release_multi_mappings on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:04:39 GMT, Mikael Vidstedt wrote: > Let's do the equivalent of problem listing the gtest/GTestWrapper.java os.release_multi_mappings sub-test (included in tier1) until JDK-8262952 is fixed. > > Note: I considered a few different ways of disabling the test on macosx-aarch64. The gtest docs (https://github.com/google/googletest/blob/master/docs/advanced.md#temporarily-disabling-tests) note, and I agree, that adding the DISABLED_ prefix is preferable over preprocessor excluding the whole test. There are several ways to add the DISABLED_ prefix conditionally, only on macosx-aarch64. In the end I found this the easiest to read and understand. This pull request has now been integrated. Changeset: fced0f08 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/fced0f08 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8265113: ProblemList gtest/GTestWrapper.java:os.release_multi_mappings on macosx-aarch64 Reviewed-by: stuefe, akozlov, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3454 From pchilanomate at openjdk.java.net Tue Apr 13 15:35:58 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Apr 2021 15:35:58 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() In-Reply-To: <3230b478-6f53-140f-e8f4-d9de3bd4b70b@oracle.com> References: <3230b478-6f53-140f-e8f4-d9de3bd4b70b@oracle.com> Message-ID: <3zdO1zTW8FEZnEG5WJhHQIqvSm6D6QKMCJSx00WKq8Y=.5815ec32-dd2d-4640-a487-551fbe47d22a@github.com> On Tue, 13 Apr 2021 02:08:00 GMT, David Holmes wrote: > On 13/04/2021 11:55 am, Patricio Chilano Mateo wrote: > > > On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo wrote: > > > Hi, > > > Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. > > > The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. > > You also need to manifest THREAD to use HAS_PENDING_EXCEPTION. I suspect > the EM was introduced purely to make THREAD available for the code > you've removed. > > I have no concerns with removing the EM if you want to. Ok, I removed the EM. Thanks! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3436 From pchilanomate at openjdk.java.net Tue Apr 13 15:35:59 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Apr 2021 15:35:59 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() [v2] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 17:11:11 GMT, Harold Seigel wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove EXCEPTION_MARK > > The changes look good. Were regression tests run? > Thanks, Harold Thanks @hseigel and @dholmes-ora for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3436 From pchilanomate at openjdk.java.net Tue Apr 13 15:36:00 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Apr 2021 15:36:00 GMT Subject: Integrated: 8265035: Remove unneeded exception check from refill_ic_stubs() In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. > The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 943503ef Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/943503ef Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod 8265035: Remove unneeded exception check from refill_ic_stubs() Reviewed-by: hseigel, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3436 From pchilanomate at openjdk.java.net Tue Apr 13 15:37:57 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Apr 2021 15:37:57 GMT Subject: RFR: 8265035: Remove unneeded exception check from refill_ic_stubs() In-Reply-To: <3230b478-6f53-140f-e8f4-d9de3bd4b70b@oracle.com> References: <3230b478-6f53-140f-e8f4-d9de3bd4b70b@oracle.com> Message-ID: <3zdO1zTW8FEZnEG5WJhHQIqvSm6D6QKMCJSx00WKq8Y=.7a0f672c-5346-48bd-b0e0-70cb8b0fb7dc@github.com> On Tue, 13 Apr 2021 02:08:00 GMT, David Holmes wrote: > On 13/04/2021 11:55 am, Patricio Chilano Mateo wrote: > > > On Mon, 12 Apr 2021 14:46:02 GMT, Patricio Chilano Mateo wrote: > > > Hi, > > > Please review this small fix. The HAS_PENDING_EXCEPTION check will always return false since EXCEPTION_MARK will check that there are no pending exceptions upon entering and VMThread::execute() doesn't throw exceptions. > > > The comment says that we could get a potential async exception, which is true, since the JT will be blocked waiting on VMOperation_lock. However delivering an async exception doesn't set the _pending_exception field, only additional fields (see JavaThread::send_thread_stop() -> set_pending_async_exception()) that will be later check in check_and_handle_async_exceptions() and only then _pending_exception will be set. > > You also need to manifest THREAD to use HAS_PENDING_EXCEPTION. I suspect > the EM was introduced purely to make THREAD available for the code > you've removed. > > I have no concerns with removing the EM if you want to. Ok, I removed the EM. Thanks! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3436 From rehn at openjdk.java.net Tue Apr 13 16:51:23 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 16:51:23 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Tue Apr 13 16:59:16 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 13 Apr 2021 16:59:16 GMT Subject: RFR: 8257831: Suspend with handshakes [v7] In-Reply-To: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> References: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> Message-ID: On Tue, 13 Apr 2021 11:57:36 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision: > > - Obsolete unused flags > - Review fixes 3 Still thumbs up. I only looked at the v06 incremental webrev. src/hotspot/share/runtime/arguments.cpp line 525: > 523: { "FlightRecorder", JDK_Version::jdk(13), JDK_Version::undefined(), JDK_Version::undefined() }, > 524: { "SuspendRetryCount", JDK_Version::jdk(16), JDK_Version::jdk(17), JDK_Version::jdk(18) }, > 525: { "SuspendRetryDelay", JDK_Version::jdk(16), JDK_Version::jdk(17), JDK_Version::jdk(18) }, I think both 'jdk(16)' values here need to be 'jdk(17)' since we didn't deprecate these option in JDK16. Or they might need to be 'JDK_Version::undefined()' since we didn't deprecate these options before obsoleting them. @dholmes-ora will know for sure. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 13 16:59:16 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 16:59:16 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 13 17:00:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 17:00:19 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From pchilanomate at openjdk.java.net Tue Apr 13 17:30:56 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Apr 2021 17:30:56 GMT Subject: RFR: 8257836: Add additional test cases to TestSyncOnValueBasedClassEvent.java In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 13:15:12 GMT, Harold Seigel wrote: > Please review this small change to add additional test cases to TestSyncOnValueBasedClassEvent.java. The modified test was tested using Mach5 on Linux x64, Linux aarch64, Mac OS and Windows. > > Thanks, Harold LGTM! Thanks, Patricio ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/3465 From david.holmes at oracle.com Tue Apr 13 21:52:28 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Apr 2021 07:52:28 +1000 Subject: RFR: 8257831: Suspend with handshakes [v7] In-Reply-To: References: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> Message-ID: On 14/04/2021 2:59 am, Daniel D.Daugherty wrote: > On Tue, 13 Apr 2021 11:57:36 GMT, Robbin Ehn wrote: > >> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision: >> >> - Obsolete unused flags >> - Review fixes 3 > > Still thumbs up. > I only looked at the v06 incremental webrev. > > src/hotspot/share/runtime/arguments.cpp line 525: > >> 523: { "FlightRecorder", JDK_Version::jdk(13), JDK_Version::undefined(), JDK_Version::undefined() }, >> 524: { "SuspendRetryCount", JDK_Version::jdk(16), JDK_Version::jdk(17), JDK_Version::jdk(18) }, >> 525: { "SuspendRetryDelay", JDK_Version::jdk(16), JDK_Version::jdk(17), JDK_Version::jdk(18) }, > > I think both 'jdk(16)' values here need to be 'jdk(17)' since > we didn't deprecate these option in JDK16. Or they might > need to be 'JDK_Version::undefined()' since we didn't > deprecate these options before obsoleting them. > @dholmes-ora will know for sure. It should be set to undefined() as they were never deprecated. Thanks, David > ------------- > > Marked as reviewed by dcubed (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3191 > From rehn at openjdk.java.net Tue Apr 13 21:55:25 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 13 Apr 2021 21:55:25 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From minqi at openjdk.java.net Tue Apr 13 23:04:24 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 13 Apr 2021 23:04:24 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v11] In-Reply-To: References: Message-ID: > Hi, Please review > > Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with > `java -XX:DumpLoadedClassList= .... ` > to collect shareable class names and saved in file `` , then > `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` > With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. > The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. > New added jcmd option: > `jcmd VM.cds static_dump ` > or > `jcmd VM.cds dynamic_dump ` > To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. > The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Fix too much verbose output, make call to stopApp after test - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Fix revert unintentionally comment, merge master. - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. - Remove redundant check for if a class is shareable - ... and 6 more: https://git.openjdk.java.net/jdk/compare/008fc75a...88c0f7d1 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2737/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=10 Stats: 860 lines in 23 files changed: 786 ins; 58 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/2737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737 PR: https://git.openjdk.java.net/jdk/pull/2737 From ysuenaga at openjdk.java.net Tue Apr 13 23:40:58 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 13 Apr 2021 23:40:58 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v4] In-Reply-To: References: <-Nst2cJnAG4QOBm6mOzLgpnbHIuUapDYuSjVl0jZZso=.40ec4b9e-0008-40cd-b9de-cdbe37a7000e@github.com> <0yqu_5IhRCJBjDLC4Nu3bg6i7yjADxS2Cu3C_IRaoF4=.5fa9d572-563d-44da-8261-78ee566b9d8a@github.com> Message-ID: <4OZsPvlm4BY8yPxlkBNVBsn10Iy6N0uOtmwfidu9fLE=.2742e16c-8b93-405e-9be5-deef0b4c3065@github.com> On Wed, 7 Apr 2021 17:02:55 GMT, Andrew Haley wrote: >>> Maybe we should just concatenate all three files? >> >> Do you mean we should concatenate "compatible", "board_name", and "product_name"? It's impossible. We can see "compatible" file on the device which uses device tree, however we cannot see both "board_name" and "product_name" on it. Thus I prefer to attempt to read them sequentially. > >> > Maybe we should just concatenate all three files? >> >> Do you mean we should concatenate "compatible", "board_name", and "product_name"? It's impossible. > > Of course it isn't impossible. But if you really want to skip a file which is just "\n", then please check for the file being just "\n", not a file with "\n" as its first character. @theRealAph The latest change uses `strncmp(buf, "\n", 2)` to check whether the content just has "\n". Are you ok this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From dcubed at openjdk.java.net Wed Apr 14 00:25:25 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Apr 2021 00:25:25 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() Message-ID: The synopsis pretty much says it all. There's a more detailed history in the RFE itself. Currently running the new test thru Mach5 Tier[1-7]. I've run the test thru several 12 hour runs on my MBP13 and on my Linux-X64 server. ------------- Commit messages: - 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() Changes: https://git.openjdk.java.net/jdk/pull/3478/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265153 Stats: 503 lines in 2 files changed: 503 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478 PR: https://git.openjdk.java.net/jdk/pull/3478 From ccheung at openjdk.java.net Wed Apr 14 00:30:03 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 14 Apr 2021 00:30:03 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive Message-ID: Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. Passed tiers 1,2,3,4 tests on mach5. ------------- Commit messages: - remove extraneous whitespace - Merge branch 'master' into 8261090-store-old-classfiles - add comments and some code simplification - 8261090: Store old classfiles in static CDS archive Changes: https://git.openjdk.java.net/jdk/pull/3479/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3479&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261090 Stats: 894 lines in 28 files changed: 852 ins; 16 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/3479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3479/head:pull/3479 PR: https://git.openjdk.java.net/jdk/pull/3479 From jiangli at openjdk.java.net Wed Apr 14 01:07:59 2021 From: jiangli at openjdk.java.net (Jiangli Zhou) Date: Wed, 14 Apr 2021 01:07:59 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:14:46 GMT, Calvin Cheung wrote: > Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. > During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. > Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. > > Passed tiers 1,2,3,4 tests on mach5. src/hotspot/share/memory/metaspaceShared.cpp line 759: > 757: Thread* THREAD = current; // For exception macros. > 758: Arguments::assert_is_dumping_archive(); > 759: if (ik->is_loaded() && !ik->is_linked() && !MetaspaceShared::is_old_class(ik) && It would be desirable to support the case when verification is not enabled, which are not rare. For old classes, bytecode rewriting and class linking can still be done at dump time in those cases, with your current proposed change that includes old classes in the archive image. Otherwise, runtime would have to spend CPU cycles to do rewriting/linking for old classes when not truly necessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/3479 From jiangli at openjdk.java.net Wed Apr 14 01:12:59 2021 From: jiangli at openjdk.java.net (Jiangli Zhou) Date: Wed, 14 Apr 2021 01:12:59 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:14:46 GMT, Calvin Cheung wrote: > Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. > During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. > Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. > > Passed tiers 1,2,3,4 tests on mach5. Could you please provide performance numbers? It would be good to understand the performance benefits from archiving the old classes when verification and linking are deferred at runtime. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3479 From whuang at openjdk.java.net Wed Apr 14 01:45:01 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 14 Apr 2021 01:45:01 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Thu, 8 Apr 2021 05:02:27 GMT, David Holmes wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> add throw exception > > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 58: > >> 56: public void test() throws Throwable { >> 57: >> 58: CountDownLatch latch = new CountDownLatch(1); > > The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives. I have tested `CyclicBarrier ` here and found that `CountDownLatch` could trigger this bug fast while `CyclicBarrier ` couldn't always trigger this bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From iklam at openjdk.java.net Wed Apr 14 01:45:03 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Apr 2021 01:45:03 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v11] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 23:04:24 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with >> `java -XX:DumpLoadedClassList= .... ` >> to collect shareable class names and saved in file `` , then >> `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` >> With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. >> The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. >> New added jcmd option: >> `jcmd VM.cds static_dump ` >> or >> `jcmd VM.cds dynamic_dump ` >> To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. >> The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Fix too much verbose output, make call to stopApp after test > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Fix revert unintentionally comment, merge master. > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. > - Remove redundant check for if a class is shareable > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/008fc75a...88c0f7d1 The latest versions looks good to me. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2737 From dholmes at openjdk.java.net Wed Apr 14 02:13:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Apr 2021 02:13:23 GMT Subject: RFR: 8257831: Suspend with handshakes [v7] In-Reply-To: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> References: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> Message-ID: On Tue, 13 Apr 2021 11:57:36 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision: > > - Obsolete unused flags > - Review fixes 3 src/hotspot/share/runtime/thread.cpp line 1446: > 1444: // The careful dance between thread suspension and exit is handled here. > 1445: // Since we are in thread_in_vm state and suspension is done with handshakes, > 1446: // we can just put in the exiting state and it will be corrcetly handled. typo: corrcetly ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 02:13:21 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 02:13:21 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dholmes at openjdk.java.net Wed Apr 14 02:18:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Apr 2021 02:18:13 GMT Subject: RFR: 8257831: Suspend with handshakes [v7] In-Reply-To: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> References: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> Message-ID: On Tue, 13 Apr 2021 11:57:36 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision: > > - Obsolete unused flags > - Review fixes 3 Latest updates look good - thanks. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 02:18:13 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 02:18:13 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 02:19:16 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 02:19:16 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dholmes at openjdk.java.net Wed Apr 14 02:31:58 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Apr 2021 02:31:58 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v4] In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> References: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> Message-ID: On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes wrote: >> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". >> >> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. >> >> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. >> >> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). >> >> Some missing CHECK_ uses were added. >> >> Testing: >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix search&replace mistake Repeating this as the bots failed to send out an email. Thanks for the reviews @coleenp , @hseigel and @iklam . Can someone from compiler team please take a look and give the okay? (I know things are a bit busy at the moment.) Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3394 From shade at openjdk.java.net Wed Apr 14 06:06:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Apr 2021 06:06:59 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v2] In-Reply-To: References: Message-ID: <3pimo04lpXews7twFmBQmv-RRSzYL9fqU8qAqkAZRR0=.5becbb13-7357-4905-a2e5-5e94cdf40b85@github.com> On Sat, 10 Apr 2021 05:59:43 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Make jcheck happy: remove the TAB > - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels Anyone? :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From rehn at openjdk.java.net Wed Apr 14 06:34:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 06:34:19 GMT Subject: RFR: 8257831: Suspend with handshakes [v7] In-Reply-To: References: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> Message-ID: <1196EWVVO0GIQHFzIFEdFCDB7JhUB14K27Ny0x04LEI=.d54726da-75ef-4c67-b0bf-7ccacd879d2a@github.com> On Wed, 14 Apr 2021 02:10:18 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision: >> >> - Obsolete unused flags >> - Review fixes 3 > > src/hotspot/share/runtime/thread.cpp line 1446: > >> 1444: // The careful dance between thread suspension and exit is handled here. >> 1445: // Since we are in thread_in_vm state and suspension is done with handshakes, >> 1446: // we can just put in the exiting state and it will be corrcetly handled. > > typo: corrcetly Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 06:34:18 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 06:34:18 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 06:42:18 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 06:42:18 GMT Subject: RFR: 8257831: Suspend with handshakes [v7] In-Reply-To: References: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> Message-ID: On Tue, 13 Apr 2021 16:49:53 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision: >> >> - Obsolete unused flags >> - Review fixes 3 > > src/hotspot/share/runtime/arguments.cpp line 525: > >> 523: { "FlightRecorder", JDK_Version::jdk(13), JDK_Version::undefined(), JDK_Version::undefined() }, >> 524: { "SuspendRetryCount", JDK_Version::jdk(16), JDK_Version::jdk(17), JDK_Version::jdk(18) }, >> 525: { "SuspendRetryDelay", JDK_Version::jdk(16), JDK_Version::jdk(17), JDK_Version::jdk(18) }, > > I think both 'jdk(16)' values here need to be 'jdk(17)' since > we didn't deprecate these option in JDK16. Or they might > need to be 'JDK_Version::undefined()' since we didn't > deprecate these options before obsoleting them. > @dholmes-ora will know for sure. Fixed with undefined() as David said. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 06:42:17 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 06:42:17 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 06:48:40 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 06:48:40 GMT Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: References: Message-ID: > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Fixed flag undef dep + spelling error ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3191/files - new: https://git.openjdk.java.net/jdk/pull/3191/files/5034e8a5..451cdd00 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=06-07 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191 PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 06:48:41 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 06:48:41 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 06:49:27 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 06:49:27 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 06:50:18 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 06:50:18 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 06:54:15 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 06:54:15 GMT Subject: RFR: 8257831: Suspend with handshakes [v7] In-Reply-To: References: <6lQLQ0naoM1J3saaG41ONZ_Fno8aZj8VuW8761B75qM=.3c69a5b3-d40b-4e85-9f66-7dfebc848608@github.com> Message-ID: On Wed, 14 Apr 2021 02:15:07 GMT, David Holmes wrote: > Latest updates look good - thanks. > > David Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 06:54:15 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 06:54:15 GMT Subject: RFR: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:44:58 GMT, David Holmes wrote: > Could be a neat use of a lambda "on_suspension_do" ... If no one else picks that up, I'll give it go after this :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From aph at redhat.com Wed Apr 14 09:28:32 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 14 Apr 2021 10:28:32 +0100 Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v4] In-Reply-To: <4OZsPvlm4BY8yPxlkBNVBsn10Iy6N0uOtmwfidu9fLE=.2742e16c-8b93-405e-9be5-deef0b4c3065@github.com> References: <-Nst2cJnAG4QOBm6mOzLgpnbHIuUapDYuSjVl0jZZso=.40ec4b9e-0008-40cd-b9de-cdbe37a7000e@github.com> <0yqu_5IhRCJBjDLC4Nu3bg6i7yjADxS2Cu3C_IRaoF4=.5fa9d572-563d-44da-8261-78ee566b9d8a@github.com> <4OZsPvlm4BY8yPxlkBNVBsn10Iy6N0uOtmwfidu9fLE=.2742e16c-8b93-405e-9be5-deef0b4c3065@github.com> Message-ID: On 4/14/21 12:40 AM, Yasumasa Suenaga wrote: > > @theRealAph The latest change uses `strncmp(buf, "\n", 2)` to check whether the content just has "\n". Are you ok this change? No, that's obviously wrong. "\n" is only one character, so it makes no sense to use strncmp(). Please check for a file containing just "\n", which is (read_sz == 1 && *buf == '\n') -- 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 ysuenaga at openjdk.java.net Wed Apr 14 12:09:14 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 14 Apr 2021 12:09:14 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v5] In-Reply-To: References: Message-ID: > `jdk.CPUInformation` event on AArch64 has valid CPU description in [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491), however it does not work on UEFI booted machine. > > [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491) refers device tree to get board name, however it does not exist on UEFI. We need to refer DMI. > However we need to have root privilege, so we refer /sys/devices/virtual/dmi/id to avoid it. > > We can get board name from /sys/devices/virtual/dmi/id/board_name, but some machine set empty string to it. So we will refer /sys/devices/virtual/dmi/id/product_name as a fallback. > > For example, we can get following CPU description on AWS A1 instance after this change: > > > jdk.CPUInformation { > startTime = 05:28:24.506 > cpu = "AArch64" > description = "AArch64 a1.2xlarge 0x41:0x0:0xd08:3, simd, crc, aes, sha1, sha256" > sockets = 8 > cores = 8 > hwThreads = 8 > } Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update conditions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3259/files - new: https://git.openjdk.java.net/jdk/pull/3259/files/a1b94754..aa53edb2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3259&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3259&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3259.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3259/head:pull/3259 PR: https://git.openjdk.java.net/jdk/pull/3259 From ysuenaga at openjdk.java.net Wed Apr 14 12:09:14 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 14 Apr 2021 12:09:14 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v5] In-Reply-To: References: Message-ID: <7-IvCAifbqsyonHdiDwQxPPcGgi46m2nSZFSSekCsBE=.4bb812a5-aa52-40dd-add4-9c4333a1419f@github.com> On Tue, 30 Mar 2021 16:20:40 GMT, Andrew Haley wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Update conditions > > This patch is basically OK, except the question about a somewhat obscure bit of code. > > @theRealAph The latest change uses `strncmp(buf, "\n", 2)` to check whether the content just has "\n". Are you ok this change? > > No, that's obviously wrong. "\n" is only one character, so it makes no sense > to use strncmp(). Please check for a file containing just "\n", which is > > (read_sz == 1 && *buf == '\n') I pushed new commit. @theRealAph Could you review again? ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From hseigel at openjdk.java.net Wed Apr 14 12:20:00 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 14 Apr 2021 12:20:00 GMT Subject: RFR: 8257836: Add additional test cases to TestSyncOnValueBasedClassEvent.java In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 13:15:12 GMT, Harold Seigel wrote: > Please review this small change to add additional test cases to TestSyncOnValueBasedClassEvent.java. The modified test was tested using Mach5 on Linux x64, Linux aarch64, Mac OS and Windows. > > Thanks, Harold Thanks Lois and Patricio for reviewing this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3465 From hseigel at openjdk.java.net Wed Apr 14 12:20:01 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 14 Apr 2021 12:20:01 GMT Subject: Integrated: 8257836: Add additional test cases to TestSyncOnValueBasedClassEvent.java In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 13:15:12 GMT, Harold Seigel wrote: > Please review this small change to add additional test cases to TestSyncOnValueBasedClassEvent.java. The modified test was tested using Mach5 on Linux x64, Linux aarch64, Mac OS and Windows. > > Thanks, Harold This pull request has now been integrated. Changeset: f5b2f089 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/f5b2f089 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8257836: Add additional test cases to TestSyncOnValueBasedClassEvent.java Reviewed-by: lfoltan, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/3465 From aph at openjdk.java.net Wed Apr 14 12:28:22 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 14 Apr 2021 12:28:22 GMT Subject: RFR: 8264412: AArch64: CPU description should refer DMI [v5] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 12:09:14 GMT, Yasumasa Suenaga wrote: >> `jdk.CPUInformation` event on AArch64 has valid CPU description in [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491), however it does not work on UEFI booted machine. >> >> [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491) refers device tree to get board name, however it does not exist on UEFI. We need to refer DMI. >> However we need to have root privilege, so we refer /sys/devices/virtual/dmi/id to avoid it. >> >> We can get board name from /sys/devices/virtual/dmi/id/board_name, but some machine set empty string to it. So we will refer /sys/devices/virtual/dmi/id/product_name as a fallback. >> >> For example, we can get following CPU description on AWS A1 instance after this change: >> >> >> jdk.CPUInformation { >> startTime = 05:28:24.506 >> cpu = "AArch64" >> description = "AArch64 a1.2xlarge 0x41:0x0:0xd08:3, simd, crc, aes, sha1, sha256" >> sockets = 8 >> cores = 8 >> hwThreads = 8 >> } > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update conditions Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From lzang at openjdk.java.net Wed Apr 14 12:35:27 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 14 Apr 2021 12:35:27 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v20] In-Reply-To: References: Message-ID: > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into par-dump - Merge branch 'master' into par-dump - Typo fix - remove parallel option and dumpheapext command - Revert "hide the dumpheapext error message" This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. - resize large object threshold - Merge branch 'master' into par-dump - Merge branch 'master' into par-dump - code clean - fix trailing white space issue - ... and 15 more: https://git.openjdk.java.net/jdk/compare/e2106d5a...997784b1 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=19 Stats: 864 lines in 6 files changed: 662 ins; 60 del; 142 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From lzang at openjdk.java.net Wed Apr 14 12:37:56 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 14 Apr 2021 12:37:56 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v19] In-Reply-To: References: Message-ID: <5rHhgI7eFyvod0YgTaEPNvp-in8GEhqFVcwvsNxVggM=.bc280d77-f713-4b90-ab03-b1dcb828c27f@github.com> On Mon, 29 Mar 2021 11:27:49 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Merge branch 'master' into par-dump > - Typo fix > - remove parallel option and dumpheapext command > - Revert "hide the dumpheapext error message" > > This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. > - resize large object threshold > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - code clean > - fix trailing white space issue > - reduce memory consumption and fix memory leak issue > - ... and 14 more: https://git.openjdk.java.net/jdk/compare/aefc1560...301cf8cd Hi Chris, I am going to close the CSR https://bugs.openjdk.java.net/browse/JDK-8260424. But it seems this PR also revised the `parallel` option's help message for `jmap -histo`, Do you think it is ok to keep the change in the PR? FYI, here is the commits https://github.com/openjdk/jdk/pull/2261/commits/6789ba291a97a01fdc70258fb25dbf0d6464dba8 Thanks, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From ysuenaga at openjdk.java.net Wed Apr 14 15:14:38 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 14 Apr 2021 15:14:38 GMT Subject: Integrated: 8264412: AArch64: CPU description should refer DMI In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 07:53:59 GMT, Yasumasa Suenaga wrote: > `jdk.CPUInformation` event on AArch64 has valid CPU description in [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491), however it does not work on UEFI booted machine. > > [JDK-8262491](https://bugs.openjdk.java.net/browse/JDK-8262491) refers device tree to get board name, however it does not exist on UEFI. We need to refer DMI. > However we need to have root privilege, so we refer /sys/devices/virtual/dmi/id to avoid it. > > We can get board name from /sys/devices/virtual/dmi/id/board_name, but some machine set empty string to it. So we will refer /sys/devices/virtual/dmi/id/product_name as a fallback. > > For example, we can get following CPU description on AWS A1 instance after this change: > > > jdk.CPUInformation { > startTime = 05:28:24.506 > cpu = "AArch64" > description = "AArch64 a1.2xlarge 0x41:0x0:0xd08:3, simd, crc, aes, sha1, sha256" > sockets = 8 > cores = 8 > hwThreads = 8 > } This pull request has now been integrated. Changeset: 0afcbd4b Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/0afcbd4b Stats: 32 lines in 1 file changed: 22 ins; 2 del; 8 mod 8264412: AArch64: CPU description should refer DMI Reviewed-by: aph, gziemski ------------- PR: https://git.openjdk.java.net/jdk/pull/3259 From dcubed at openjdk.java.net Wed Apr 14 15:37:00 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Apr 2021 15:37:00 GMT Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 06:48:40 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed flag undef dep + spelling error Reviewed v07 incremental. Still looks good. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 14 15:37:00 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Apr 2021 15:37:00 GMT Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: References: Message-ID: <6EyFHmoROs_E0zjIIZ-ilTWB3gixzWcYZhd9f0wnz6c=.461ee272-6b16-4519-b541-b66921d9b550@github.com> On Wed, 14 Apr 2021 15:31:21 GMT, Daniel D. Daugherty wrote: > Reviewed v07 incremental. Still looks good. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From ccheung at openjdk.java.net Wed Apr 14 16:10:53 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 14 Apr 2021 16:10:53 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v11] In-Reply-To: References: Message-ID: <2MZBR7N1LLVc5ZpiuP9b6IBzhekgk4gCwz2EkY6xv7k=.60f0234f-61fb-4f29-b68e-08f0a92ca3de@github.com> On Tue, 13 Apr 2021 23:04:24 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with >> `java -XX:DumpLoadedClassList= .... ` >> to collect shareable class names and saved in file `` , then >> `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` >> With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. >> The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. >> New added jcmd option: >> `jcmd VM.cds static_dump ` >> or >> `jcmd VM.cds dynamic_dump ` >> To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. >> The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Fix too much verbose output, make call to stopApp after test > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Fix revert unintentionally comment, merge master. > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. > - Remove redundant check for if a class is shareable > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/008fc75a...88c0f7d1 src/hotspot/share/memory/dynamicArchive.cpp line 348: > 346: set_has_been_dumped_once(); > 347: } > 348: assert(ArchiveClassesAtExit == nullptr, "already checked in arguments.cpp?"); Same assert has been done at line 338. test/hotspot/jtreg/runtime/cds/appcds/DumpClassList.java line 89: > 87: output.shouldContain("skip writing class java/lang/NewClass"); > 88: // but classes on -Xbootclasspath/a should not be skipped > 89: output.shouldNotContain("skip writing class boot/append/Foo"); Why was the above checks removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/2737 From ccheung at openjdk.java.net Wed Apr 14 16:16:45 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 14 Apr 2021 16:16:45 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v11] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 23:04:24 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with >> `java -XX:DumpLoadedClassList= .... ` >> to collect shareable class names and saved in file `` , then >> `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` >> With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. >> The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. >> New added jcmd option: >> `jcmd VM.cds static_dump ` >> or >> `jcmd VM.cds dynamic_dump ` >> To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. >> The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Fix too much verbose output, make call to stopApp after test > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Fix revert unintentionally comment, merge master. > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. > - Remove redundant check for if a class is shareable > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/008fc75a...88c0f7d1 Looks good. Just have a few minor comments. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTest.java line 86: > 84: bootJar = JarBuilder.build("boot", BOOT_CLASSES); > 85: Path testJarPath = FileSystems.getDefault().getPath(testJar); > 86: Path bootJarPath = FileSystems.getDefault().getPath(bootJar); I think the above could be replaced with: String testJarPath = TestCommon.getTestJar(?test.jar?); String bootJarPath = TestCommon.getTestJar(?boot.jar?); Most of the CDS tests use the `getTestJar` method. You can leave it as is if you like. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTest.java line 149: > 147: args.add("-Xlog:class+load"); > 148: > 149: LingeredApp app = createLingeredApp(args.toArray(new String[0])); Instead of `new String[0]`, I think it is more intuitive to use `new String[args.size()]`. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2737 From dcubed at openjdk.java.net Wed Apr 14 16:22:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Apr 2021 16:22:58 GMT Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 06:48:40 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed flag undef dep + spelling error Reviewed v07 incremental. Still looks good. Update: Did a crawl thru review of v07 full from the bottom up. I'm hoping the change in review order results in less "change blindness" since I've reviewed so many times. There are a few left overs that still need to be address. There are a couple buried in "resolved comments" where it looks like the issue that I raised is not actually resolved. src/hotspot/share/runtime/handshake.hpp line 99: > 97: // but we need to check for a safepoint before. > 98: // (this is due to a suspension handshake which put the JavaThread in blocked > 99: // state so a safepoint may be in-progress) nit: s/(this/(This/ nit: s/in-progress)/in-progress.)/ src/hotspot/share/runtime/handshake.hpp line 166: > 164: // thread gets suspended again (after a resume) > 165: // and we have not yet processed it. > 166: bool _async_suspend_handshake; Does this need to be `volatile`? src/hotspot/share/runtime/handshake.hpp line 177: > 175: void set_suspended(bool to) { return Atomic::store(&_suspended, to); } > 176: bool has_async_suspend_handshake() { return _async_suspend_handshake; } > 177: void set_async_suspend_handshake(bool to) { _async_suspend_handshake = to; } Does this need to be an Atomic::store? src/hotspot/share/runtime/objectMonitor.cpp line 424: > 422: // thread that suspended us. > 423: _recursions = 0; > 424: _succ = NULL; You might want to add a comment here: // Don't need a full fence after clearing successor here because of the call to exit(). ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Wed Apr 14 16:22:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Apr 2021 16:22:58 GMT Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 07:23:26 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/handshake.cpp line 415: >> >>> 413: // Adds are done lock free and so is arming. >>> 414: // Calling this method with lock held is considered an error. >>> 415: assert(!_lock.owned_by_self(), "Lock should not be held"); >> >> If adds are still lock-free then why was this assertion removed? > > Because we add the async handshake inside the sync handshake and thus we already hold the _lock. @robehn - You still haven't addressed this one... ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Wed Apr 14 16:22:59 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Apr 2021 16:22:59 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: References: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> Message-ID: On Mon, 12 Apr 2021 07:48:10 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 970: >> >>> 968: >>> 969: current->frame_anchor()->make_walkable(current); >>> 970: OrderAccess::storestore(); >> >> Needs a comment explaining what the memory sync is for. > > Fixed I'm not seeing the comment here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Wed Apr 14 16:36:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Apr 2021 16:36:56 GMT Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 06:48:40 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed flag undef dep + spelling error I dug out the comments that I made in "resolved" sections where the original comment wasn't actually resolved. I posted new comments so let's see if those show up in the emails... src/hotspot/share/runtime/handshake.cpp line 415: > 413: // Adds are done lock free and so is arming. > 414: // Calling this method with lock held is considered an error. > 415: assert(!_lock.owned_by_self(), "Lock should not be held"); I originally added this comment inside the "resolved" conversation and that kept this comment from showing up. Let's try it as a new comment. Doesn't that mean the comment on L415 needs updating? Should it be something like: // Synchronous adds are done lock free and so is arming, but some // asynchronous adds are done when we already hold the lock. I'm not sure about the "some asynchronous adds" part... @dcubed-ojdk src/hotspot/share/runtime/objectMonitor.cpp line 972: > 970: > 971: current->frame_anchor()->make_walkable(current); > 972: OrderAccess::storestore(); Repeating this comment since my original is marked resolved, but I'm not seeing a new comment here. I originally pointed this out in the resolved conversation, but that doesn't make the comment show up in the review emails. Needs a comment explaining what the memory sync is for. src/hotspot/share/runtime/objectMonitor.cpp line 1559: > 1557: if (_succ == current) { > 1558: _succ = NULL; > 1559: OrderAccess::fence(); My original comment is marked "fixed", but I don't see the new comment: Please add a comment to this line: OrderAccess::fence(); // always do a full fence when successor is cleared ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From vlivanov at openjdk.java.net Wed Apr 14 17:17:40 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 14 Apr 2021 17:17:40 GMT Subject: RFR: 8264188: Improve handling of assembly files in the JDK [v2] In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 10:48:55 GMT, Magnus Ihse Bursie wrote: >> We have a handful of assembly files in the JDK. They have long been left aside, with a "if it ain't broken, don't fix it" attitude. >> >> In the current panama-vector, there is a lot more assembly files incoming, including for the Windows platforrm, which has not existed for a long time in the JDK. >> >> It is time to give assembly files some more love and care. This patch cleans up the handling in the build system, and it unifies between .s and .S files. >> >> For historical reasons, .s has been the suffix used in the posix world to signify assembly output as generated by a compiler, and .S to signify "hand-written" precious assembly. One effect of this is that gcc and clang will run the preprocessor on files named .S but not on files named .s. >> >> All our files are "hand-written" in this sense, and should have the .S suffix. But not all had. On mac, it was even worse, where the files were named .s but the option `-x assembler-with-cpp` was used to force clang to treat them as .S files instead... This change however made the preprocesser try to parse comments of the form >> >> # if (a) { >> >> as preprocessor directives, and balk at them. In one of the files, I had to wrap this in preprocessor comments (`/* ... */`). >> >> We also had inconsistent handling on dependencies. For preprocessed assembly files, it really makes sense to have dependency tracking, exactly as for C/C++ files. Now the dependency tracking in NativeCompilation is simplified, and applies to all files. (The sole exception is Windows assembly, since masm is unable to output dependency information, even though it is able to include files :-(). >> >> This patch has been partly written by Sandhya Viswanathan for the panama-vector repo. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Use OPENJDK_BUILD_CPU_BITS instead Looks good! Thanks a lot for taking care of it. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3198 From hseigel at openjdk.java.net Wed Apr 14 18:31:43 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 14 Apr 2021 18:31:43 GMT Subject: RFR: 8257804 Test runtime/modules/ModuleStress/ModuleStressGC.java fails: 'package test defined in module jdk.test, exports list being walked' missing from stdout/stderr Message-ID: <1K82ZDx2FI0xPJS6xNRKxEw_-bXcHBdbmZ1c3PBFMT8=.42faddae-7dca-4532-b7b5-7e802a283f7a@github.com> Please review this small test change to reduce the size of the Java heap used by the test so that the test's call to System.gc() is potentially more likely to walk the JVM's module reads-list and exports-list structures. The modified test was tested on Linux, Mac OS, and run 1000 times on Windows, where the previous failures had occurred. Thanks, Harold ------------- Commit messages: - 8257804 Test runtime/modules/ModuleStress/ModuleStressGC.java fails: 'package test defined in module jdk.test, exports list being walked' missing from stdout/stderr Changes: https://git.openjdk.java.net/jdk/pull/3497/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3497&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257804 Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3497.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3497/head:pull/3497 PR: https://git.openjdk.java.net/jdk/pull/3497 From mikael at openjdk.java.net Wed Apr 14 18:44:50 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 14 Apr 2021 18:44:50 GMT Subject: RFR: 8265235: ProblemList java/foreign/TestIntrinsics.java on macosx-aarch64 Message-ID: Let's problem list java/foreign/TestIntrinsics.java (a tier1 test) until JDK-8265183 is fixed. ------------- Commit messages: - 8265235: ProblemList java/foreign/TestIntrinsics.java on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3499/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3499&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265235 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3499.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3499/head:pull/3499 PR: https://git.openjdk.java.net/jdk/pull/3499 From mikael at openjdk.java.net Wed Apr 14 18:45:52 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 14 Apr 2021 18:45:52 GMT Subject: RFR: 8265236: ProblemList java/foreign/TestUpcall.java on macosx-aarch64 Message-ID: Let's problem list java/foreign/TestUpcall.java (a tier1 test) until JDK-8265182 is fixed. ------------- Depends on: https://git.openjdk.java.net/jdk/pull/3499 Commit messages: - 8265236: ProblemList java/foreign/TestUpcall.java on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3500/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3500&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265236 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3500/head:pull/3500 PR: https://git.openjdk.java.net/jdk/pull/3500 From minqi at openjdk.java.net Wed Apr 14 19:08:25 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 14 Apr 2021 19:08:25 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v12] In-Reply-To: References: Message-ID: <3a_niaHCAlxycKq7lSyi6QWCntKhwGQXqjVN1d1D2SQ=.a85bfd81-7b5c-4416-b73a-d817e830aefd@github.com> > Hi, Please review > > Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with > `java -XX:DumpLoadedClassList= .... ` > to collect shareable class names and saved in file `` , then > `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` > With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. > The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. > New added jcmd option: > `jcmd VM.cds static_dump ` > or > `jcmd VM.cds dynamic_dump ` > To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. > The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Removed extra assert and fixed extra Path usage in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2737/files - new: https://git.openjdk.java.net/jdk/pull/2737/files/88c0f7d1..042ec8f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=10-11 Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737 PR: https://git.openjdk.java.net/jdk/pull/2737 From dcubed at openjdk.java.net Wed Apr 14 19:16:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Apr 2021 19:16:09 GMT Subject: RFR: 8265235: ProblemList java/foreign/TestIntrinsics.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 18:36:22 GMT, Mikael Vidstedt wrote: > Let's problem list java/foreign/TestIntrinsics.java (a tier1 test) until JDK-8265183 is fixed. Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3499 From dcubed at openjdk.java.net Wed Apr 14 19:18:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Apr 2021 19:18:56 GMT Subject: RFR: 8265236: ProblemList java/foreign/TestUpcall.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 18:40:03 GMT, Mikael Vidstedt wrote: > Let's problem list java/foreign/TestUpcall.java (a tier1 test) until JDK-8265182 is fixed. Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3500 From mikael at openjdk.java.net Wed Apr 14 19:22:42 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 14 Apr 2021 19:22:42 GMT Subject: Integrated: 8265235: ProblemList java/foreign/TestIntrinsics.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 18:36:22 GMT, Mikael Vidstedt wrote: > Let's problem list java/foreign/TestIntrinsics.java (a tier1 test) until JDK-8265183 is fixed. This pull request has now been integrated. Changeset: 57f86a07 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/57f86a07 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8265235: ProblemList java/foreign/TestIntrinsics.java on macosx-aarch64 Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3499 From mikael at openjdk.java.net Wed Apr 14 19:26:04 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 14 Apr 2021 19:26:04 GMT Subject: RFR: 8265236: ProblemList java/foreign/TestUpcall.java on macosx-aarch64 [v2] In-Reply-To: References: Message-ID: <8l-cR5RXimkfL2jokX-MEtXVrbHeTHEhPMtTA55Oo3o=.8bc96445-91f7-4c89-8139-d3fc8e21be17@github.com> > Let's problem list java/foreign/TestUpcall.java (a tier1 test) until JDK-8265182 is fixed. Mikael Vidstedt 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. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3500/files - new: https://git.openjdk.java.net/jdk/pull/3500/files/681582c2..681582c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3500&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3500&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3500/head:pull/3500 PR: https://git.openjdk.java.net/jdk/pull/3500 From mikael at openjdk.java.net Wed Apr 14 19:57:04 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 14 Apr 2021 19:57:04 GMT Subject: RFR: 8265236: ProblemList java/foreign/TestUpcall.java on macosx-aarch64 [v3] In-Reply-To: References: Message-ID: > Let's problem list java/foreign/TestUpcall.java (a tier1 test) until JDK-8265182 is fixed. Mikael Vidstedt 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 8265236-plist-8265182 - 8265236: ProblemList java/foreign/TestUpcall.java on macosx-aarch64 - 8265235: ProblemList java/foreign/TestIntrinsics.java on macosx-aarch64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3500/files - new: https://git.openjdk.java.net/jdk/pull/3500/files/681582c2..c5453f8b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3500&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3500&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3500/head:pull/3500 PR: https://git.openjdk.java.net/jdk/pull/3500 From mikael at openjdk.java.net Wed Apr 14 19:57:05 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 14 Apr 2021 19:57:05 GMT Subject: Integrated: 8265236: ProblemList java/foreign/TestUpcall.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 18:40:03 GMT, Mikael Vidstedt wrote: > Let's problem list java/foreign/TestUpcall.java (a tier1 test) until JDK-8265182 is fixed. This pull request has now been integrated. Changeset: 05f851e4 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/05f851e4 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8265236: ProblemList java/foreign/TestUpcall.java on macosx-aarch64 Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3500 From github.com+16741972+whjpji at openjdk.java.net Wed Apr 14 22:15:40 2021 From: github.com+16741972+whjpji at openjdk.java.net (Frank King) Date: Wed, 14 Apr 2021 22:15:40 GMT Subject: RFR: 8265120: hs_err improvement: align the output of Virtual space metadata Message-ID: In the "virtual space" section of the VM error log, the "Both" line doesn't align well will the above two lines - there is a redundant leading space in this line. Metaspace: Usage: Non-class: 216.95 KB used. Class: 10.45 KB used. Both: 227.40 KB used. Virtual space: Non-class space: 8.00 MB reserved, 320.00 KB ( 4%) committed, 1 nodes. Class space: 1.00 GB reserved, 128.00 KB ( <1%) committed, 1 nodes. Both: 1.01 GB reserved, 448.00 KB ( <1%) committed. <---- Not aligned here It can be simply fixed by removing the redundant space in function `print_vs` in `src/hotspot/share/memory/metaspace/metaspaceReporter.cpp`. Here is the fixed result: Metaspace: Usage: Non-class: 216.95 KB used. Class: 10.45 KB used. Both: 227.40 KB used. Virtual space: Non-class space: 8.00 MB reserved, 320.00 KB ( 4%) committed, 1 nodes. Class space: 1.00 GB reserved, 128.00 KB ( <1%) committed, 1 nodes. Both: 1.01 GB reserved, 448.00 KB ( <1%) committed. <----- Fixed ------------- Commit messages: - 8265120: hs_err improvement: align the output of Virtual space metadata. Changes: https://git.openjdk.java.net/jdk/pull/3458/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3458&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265120 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3458.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3458/head:pull/3458 PR: https://git.openjdk.java.net/jdk/pull/3458 From sspitsyn at openjdk.java.net Wed Apr 14 23:09:53 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 14 Apr 2021 23:09:53 GMT Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 06:48:40 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed flag undef dep + spelling error src/hotspot/share/prims/jvmtiEnv.cpp line 952: > 950: if (!JvmtiSuspendControl::suspend(java_thread)) { > 951: // Either the thread is already suspended or > 952: // the thread was in the process of exiting: Nit: replace this line with: "// it was in process of exiting." src/hotspot/share/prims/jvmtiEnv.cpp line 993: > 991: if (!JvmtiSuspendControl::suspend(java_thread)) { > 992: // Either the thread is already suspended or > 993: // the thread was in the process of exiting: Nit: replace this line with: "// it was in process of exiting." src/hotspot/share/prims/jvmtiEnv.cpp line 998: > 996: continue; > 997: } > 998: results[i] = JVMTI_ERROR_THREAD_SUSPENDED; Nit: Remove one extra space after '='. src/hotspot/share/prims/jvmtiEnv.cpp line 1006: > 1004: if (!JvmtiSuspendControl::suspend(current)) { > 1005: // Either the thread is already suspended or > 1006: // the thread was in the process of exiting: Nit: replace this line with: "// it was in process of exiting." src/hotspot/share/prims/jvmtiEnv.cpp line 1010: > 1008: results[self_index] = JVMTI_ERROR_THREAD_NOT_ALIVE; > 1009: } else { > 1010: results[self_index] = JVMTI_ERROR_THREAD_SUSPENDED; Nit: Remove one extra space after '='. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From sspitsyn at openjdk.java.net Wed Apr 14 23:14:52 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 14 Apr 2021 23:14:52 GMT Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: References: Message-ID: <7lr-BFiqmT_Zh6rPM8iawfNEbzkbp16Yq8kW_lx2vvs=.5f41e815-762e-4c76-a758-eca5fbe40f52@github.com> On Wed, 14 Apr 2021 06:48:40 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed flag undef dep + spelling error It looks good. I do not see any serviceability related related issues but posted some nits. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From dholmes at openjdk.java.net Wed Apr 14 23:52:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Apr 2021 23:52:33 GMT Subject: RFR: 8257804 Test runtime/modules/ModuleStress/ModuleStressGC.java fails: 'package test defined in module jdk.test, exports list being walked' missing from stdout/stderr In-Reply-To: <1K82ZDx2FI0xPJS6xNRKxEw_-bXcHBdbmZ1c3PBFMT8=.42faddae-7dca-4532-b7b5-7e802a283f7a@github.com> References: <1K82ZDx2FI0xPJS6xNRKxEw_-bXcHBdbmZ1c3PBFMT8=.42faddae-7dca-4532-b7b5-7e802a283f7a@github.com> Message-ID: <1MBeBeSfgt3kk063mlexFPbzM9YFODoeIHHXaX-Zg50=.194c7a5b-af7a-460f-ae50-4158dec72c50@github.com> On Wed, 14 Apr 2021 18:25:04 GMT, Harold Seigel wrote: > Please review this small test change to reduce the size of the Java heap used by the test so that the test's call to System.gc() is potentially more likely to walk the JVM's module reads-list and exports-list structures. > > The modified test was tested on Linux, Mac OS, and run 1000 times on Windows, where the previous failures had occurred. > > Thanks, Harold Hi Harold, Seems fine and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3497 From kvn at openjdk.java.net Wed Apr 14 23:52:34 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 14 Apr 2021 23:52:34 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v4] In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> References: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> Message-ID: <7Z7WVmrAwRFOZLRr7WpgBhbfpuCXOwMHZQ7xPM50Vt0=.b5cee83a-1bd6-4838-92d5-e9e1057479a5@github.com> On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes wrote: >> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". >> >> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. >> >> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. >> >> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). >> >> Some missing CHECK_ uses were added. >> >> Testing: >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix search&replace mistake Why you kept `JavaThread *thread` parameter in some methods and renamed in others in deoptimization.* files. src/hotspot/share/c1/c1_Runtime1.cpp line 178: > 176: // Stress deoptimization > 177: static void deopt_caller(JavaThread* current) { > 178: if ( !caller_is_deopted(current)) { Can you remove space after `( `? ------------- PR: https://git.openjdk.java.net/jdk/pull/3394 From david.holmes at oracle.com Wed Apr 14 23:53:58 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Apr 2021 09:53:58 +1000 Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: References: Message-ID: On 15/04/2021 2:22 am, Daniel D.Daugherty wrote: > On Wed, 7 Apr 2021 07:23:26 GMT, Robbin Ehn wrote: > >>> src/hotspot/share/runtime/handshake.cpp line 415: >>> >>>> 413: // Adds are done lock free and so is arming. >>>> 414: // Calling this method with lock held is considered an error. >>>> 415: assert(!_lock.owned_by_self(), "Lock should not be held"); >>> >>> If adds are still lock-free then why was this assertion removed? >> >> Because we add the async handshake inside the sync handshake and thus we already hold the _lock. > > @robehn - You still haven't addressed this one... Assuming your comment is attributed to the correct comments, this is addressed. The assert has to be removed because we can own the lock. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3191 > From kvn at openjdk.java.net Thu Apr 15 00:06:35 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 15 Apr 2021 00:06:35 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v4] In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> References: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> Message-ID: On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes wrote: >> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". >> >> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. >> >> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. >> >> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). >> >> Some missing CHECK_ uses were added. >> >> Testing: >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix search&replace mistake I also don't see changes in `src/hotspot/share/ci/`. Is code there okay? ------------- PR: https://git.openjdk.java.net/jdk/pull/3394 From david.holmes at oracle.com Thu Apr 15 00:16:26 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Apr 2021 10:16:26 +1000 Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v4] In-Reply-To: <7Z7WVmrAwRFOZLRr7WpgBhbfpuCXOwMHZQ7xPM50Vt0=.b5cee83a-1bd6-4838-92d5-e9e1057479a5@github.com> References: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> <7Z7WVmrAwRFOZLRr7WpgBhbfpuCXOwMHZQ7xPM50Vt0=.b5cee83a-1bd6-4838-92d5-e9e1057479a5@github.com> Message-ID: <3352b004-d6ba-6bdf-3ee6-663a12414f1c@oracle.com> Hi Vladimir, Thanks for looking at this. On 15/04/2021 9:52 am, Vladimir Kozlov wrote: > On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes wrote: > >>> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". >>> >>> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. >>> >>> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. >>> >>> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). >>> >>> Some missing CHECK_ uses were added. >>> >>> Testing: >>> - tiers 1-3 >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix search&replace mistake > > Why you kept `JavaThread *thread` parameter in some methods and renamed in others in deoptimization.* files. I only changed those parameters involved with JRT_* routines, as those can obviously be seen to be the current thread. For other code in that file it probably deals with the current thread, but that isn't necessarily obvious and would need more rigorous checking. That is beyond the scope of the current set of changes and would need a future RFE. Similarly for the lack of changes in the ci files - if they weren't affected by the JRT changes they weren't changed. > src/hotspot/share/c1/c1_Runtime1.cpp line 178: > >> 176: // Stress deoptimization >> 177: static void deopt_caller(JavaThread* current) { >> 178: if ( !caller_is_deopted(current)) { > > Can you remove space after `( `? Sure. :) Thanks, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3394 > From kvn at openjdk.java.net Thu Apr 15 01:08:36 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 15 Apr 2021 01:08:36 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v4] In-Reply-To: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> References: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> Message-ID: On Fri, 9 Apr 2021 05:08:37 GMT, David Holmes wrote: >> The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". >> >> The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. >> >> We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. >> >> Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). >> >> Some missing CHECK_ uses were added. >> >> Testing: >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix search&replace mistake Okay. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3394 From dholmes at openjdk.java.net Thu Apr 15 02:20:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Apr 2021 02:20:09 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v5] In-Reply-To: References: Message-ID: > The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". > > The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. > > We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. > > Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). > > Some missing CHECK_ uses were added. > > Testing: > - tiers 1-3 > > Thanks, > David David Holmes 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 ten additional commits since the last revision: - Merge branch 'master' into jrt_entry_v2 - Fix style nit for kvn - Merge branch 'master' into jrt_entry_v2 - Fix search&replace mistake - Fix minor nits reported by @coleenp and @hseigel - @coleenp review comment - Avoid manifesting JavaThread::current() when it can be passed in - Added in missed JRT_BLOCK_ENTRY methods in AOT-related jvmci/compilerRuntime.cpp - Fixed CHECK on return statement. - 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3394/files - new: https://git.openjdk.java.net/jdk/pull/3394/files/9cfc43c2..166c7fe5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3394&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3394&range=03-04 Stats: 17123 lines in 917 files changed: 10458 ins; 5286 del; 1379 mod Patch: https://git.openjdk.java.net/jdk/pull/3394.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3394/head:pull/3394 PR: https://git.openjdk.java.net/jdk/pull/3394 From dholmes at openjdk.java.net Thu Apr 15 02:25:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Apr 2021 02:25:35 GMT Subject: Integrated: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 06:52:15 GMT, David Holmes wrote: > The existing JRT_ENTRY (and related) macros require the function to which they are applied to declare a parameter "JavaThread* thread" which represents the current thread. These functions are all implicitly "traps" functions as they can result in exceptions, but they are not declared with TRAPS because the only caller of these functions is the runtime itself (via call_VM) and no callers need to be aware to use CHECK; further they need a JavaThread. So the macro declares the THREAD variable for use with other exception-producing functions and assigns it from "thread". > > The majority of this change replaces the parameter name "thread" with "current" so that it is clear that we are always dealing with the current thread. This affects the entry functions as well as the functions called therefrom. > > We can then also replace the use of "THREAD" with "current", in contexts that are not related to exception processing. > > Some methods called by entry functions were declared to have both a "thread" parameter and a "TRAPS" parameter - with nothing to tell you these are always the same, current, thread. So the "thread" parameter is removed and replaced with a local variable "current" obtained from THREAD->as_Java_thread(). > > Some missing CHECK_ uses were added. > > Testing: > - tiers 1-3 > > Thanks, > David This pull request has now been integrated. Changeset: 79bff21b Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/79bff21b Stats: 936 lines in 23 files changed: 16 ins; 29 del; 891 mod 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines Reviewed-by: coleenp, hseigel, iklam, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/3394 From dholmes at openjdk.java.net Thu Apr 15 02:25:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Apr 2021 02:25:34 GMT Subject: RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines [v4] In-Reply-To: References: <_q9nVMOqIePMWqifBZo_Cj9Vsal63l2BLN8X7x5S8iw=.abdcc58f-877d-4e36-b26e-3699cb05eeda@github.com> Message-ID: On Thu, 15 Apr 2021 00:03:22 GMT, Vladimir Kozlov wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix search&replace mistake > > I also don't see changes in `src/hotspot/share/ci/`. Is code there okay? Thanks for the review @vnkozlov ! David ------------- PR: https://git.openjdk.java.net/jdk/pull/3394 From mli at openjdk.java.net Thu Apr 15 03:14:41 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 15 Apr 2021 03:14:41 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v12] In-Reply-To: <3a_niaHCAlxycKq7lSyi6QWCntKhwGQXqjVN1d1D2SQ=.a85bfd81-7b5c-4416-b73a-d817e830aefd@github.com> References: <3a_niaHCAlxycKq7lSyi6QWCntKhwGQXqjVN1d1D2SQ=.a85bfd81-7b5c-4416-b73a-d817e830aefd@github.com> Message-ID: On Wed, 14 Apr 2021 19:08:25 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with >> `java -XX:DumpLoadedClassList= .... ` >> to collect shareable class names and saved in file `` , then >> `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` >> With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. >> The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. >> New added jcmd option: >> `jcmd VM.cds static_dump ` >> or >> `jcmd VM.cds dynamic_dump ` >> To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. >> The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Removed extra assert and fixed extra Path usage in test Marked as reviewed by mli (Reviewer). I looked back at the history, and find out why it calls from JVM into java then into JVM again, nice solution! ------------- PR: https://git.openjdk.java.net/jdk/pull/2737 From dholmes at openjdk.java.net Thu Apr 15 04:56:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Apr 2021 04:56:34 GMT Subject: RFR: 8265120: hs_err improvement: align the output of Virtual space metadata In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 09:51:01 GMT, Frank King wrote: > In the "virtual space" section of the VM error log, the "Both" line doesn't align well will the above two lines - there is a redundant leading space in this line. > > > Metaspace: > > Usage: > Non-class: 216.95 KB used. > Class: 10.45 KB used. > Both: 227.40 KB used. > > Virtual space: > Non-class space: 8.00 MB reserved, 320.00 KB ( 4%) committed, 1 nodes. > Class space: 1.00 GB reserved, 128.00 KB ( <1%) committed, 1 nodes. > Both: 1.01 GB reserved, 448.00 KB ( <1%) committed. <---- Not aligned here > > > It can be simply fixed by removing the redundant space in function `print_vs` in `src/hotspot/share/memory/metaspace/metaspaceReporter.cpp`. > > Here is the fixed result: > > Metaspace: > > Usage: > Non-class: 216.95 KB used. > Class: 10.45 KB used. > Both: 227.40 KB used. > > Virtual space: > Non-class space: 8.00 MB reserved, 320.00 KB ( 4%) committed, 1 nodes. > Class space: 1.00 GB reserved, 128.00 KB ( <1%) committed, 1 nodes. > Both: 1.01 GB reserved, 448.00 KB ( <1%) committed. <----- Fixed This is a trivial fix. I will sponsor this for you. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3458 From github.com+16741972+whjpji at openjdk.java.net Thu Apr 15 05:07:36 2021 From: github.com+16741972+whjpji at openjdk.java.net (Frank King) Date: Thu, 15 Apr 2021 05:07:36 GMT Subject: RFR: 8265120: hs_err improvement: align the output of Virtual space metadata In-Reply-To: References: Message-ID: <4w6hfI5yThJtNB-B5pl0e58kZXOXAH27Xgg2bNL1WCo=.0e55757f-8201-4c64-8528-24cfedbc1373@github.com> On Thu, 15 Apr 2021 04:53:34 GMT, David Holmes wrote: > This is a trivial fix. I will sponsor this for you. > > Thanks, > David Thanks @dholmes-ora ! ------------- PR: https://git.openjdk.java.net/jdk/pull/3458 From minqi at openjdk.java.net Thu Apr 15 05:24:41 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Apr 2021 05:24:41 GMT Subject: Integrated: 8259070: Add jcmd option to dump CDS In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 00:03:40 GMT, Yumin Qi wrote: > Hi, Please review > > Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with > `java -XX:DumpLoadedClassList= .... ` > to collect shareable class names and saved in file `` , then > `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` > With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. > The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. > New added jcmd option: > `jcmd VM.cds static_dump ` > or > `jcmd VM.cds dynamic_dump ` > To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. > The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin This pull request has now been integrated. Changeset: e7cbeba8 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/e7cbeba8 Stats: 857 lines in 23 files changed: 783 ins; 58 del; 16 mod 8259070: Add jcmd option to dump CDS Reviewed-by: ccheung, iklam, mli ------------- PR: https://git.openjdk.java.net/jdk/pull/2737 From minqi at openjdk.java.net Thu Apr 15 05:24:38 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Apr 2021 05:24:38 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v12] In-Reply-To: References: Message-ID: <6rB1bQQTIMyzBIPTaK-GTib06tleC6MQlmM6Xy_m8VM=.cf46161f-872a-442f-9229-a02045bc4de9@github.com> On Sat, 27 Feb 2021 18:20:52 GMT, Ioi Lam wrote: >> Hi Yumin, >> >> This is a very useful addition. >> >> My biggest concern with this patch though is the use of `os::fork_and_exec()` in regular, non-fatal situations. I had a look at that function and I think that is very unsafe. >> >> - it does not close file descriptors, so the child vm will inherit all file descriptors not opened with FD_CLOEXEC. In Runtime.exec, we do this whole dance around safely closing off all unused file descriptors, which is missing here. Note that even though we mostly open all fds with CLOEXEC, this does not matter, since user code may not do that. >> - It uses vfork "if available", which is probably always, but that may be okay since the child exec's right away. Still, vfork makes me nervous. >> - Weirdly enough, it always spawns the child program via one indirection using a shell; so there is always the shell between you and your spawned VM, and you probably wont get the return code of your child vm process back. >> >> Until now, os::fork_and_exec() was only used in fatal situations where the VM was about to die anyway. And where it did not really matter if it worked or not. >> >> If we now want to use it in regular situations, we need to give that thing an overhaul and make it a first class fork api, and also test it better that it is today. The file descriptor issue has to be addressed at the very least. >> >> I really would consider rewriting the whole thing using posix_spawn. Since JDK15 I think posix_spawn is the default for Runtime.exec, so we know it works well. I would also do this in a separate RFE. >> >> Alternatively, you could call into java and use Runtime.exec(). >> >> Further remarks inline. >> >> Thanks, Thomas > >> I really would consider rewriting the whole thing using posix_spawn. Since JDK15 I think posix_spawn is the default for Runtime.exec, so we know it works well. I would also do this in a separate RFE. >> >> Alternatively, you could call into java and use Runtime.exec(). > > I think we should call into Java and use `Runtime.exec()`. Running a subprocess is very complicated, so we shouldn't try to duplicate the code in the VM. @iklam @calvinccheung @Hamlin-Li Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2737 From github.com+16741972+whjpji at openjdk.java.net Thu Apr 15 05:43:34 2021 From: github.com+16741972+whjpji at openjdk.java.net (Frank King) Date: Thu, 15 Apr 2021 05:43:34 GMT Subject: Integrated: 8265120: hs_err improvement: align the output of Virtual space metadata In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 09:51:01 GMT, Frank King wrote: > In the "virtual space" section of the VM error log, the "Both" line doesn't align well will the above two lines - there is a redundant leading space in this line. > > > Metaspace: > > Usage: > Non-class: 216.95 KB used. > Class: 10.45 KB used. > Both: 227.40 KB used. > > Virtual space: > Non-class space: 8.00 MB reserved, 320.00 KB ( 4%) committed, 1 nodes. > Class space: 1.00 GB reserved, 128.00 KB ( <1%) committed, 1 nodes. > Both: 1.01 GB reserved, 448.00 KB ( <1%) committed. <---- Not aligned here > > > It can be simply fixed by removing the redundant space in function `print_vs` in `src/hotspot/share/memory/metaspace/metaspaceReporter.cpp`. > > Here is the fixed result: > > Metaspace: > > Usage: > Non-class: 216.95 KB used. > Class: 10.45 KB used. > Both: 227.40 KB used. > > Virtual space: > Non-class space: 8.00 MB reserved, 320.00 KB ( 4%) committed, 1 nodes. > Class space: 1.00 GB reserved, 128.00 KB ( <1%) committed, 1 nodes. > Both: 1.01 GB reserved, 448.00 KB ( <1%) committed. <----- Fixed This pull request has now been integrated. Changeset: 7c6e3796 Author: Junji Wang Committer: David Holmes URL: https://git.openjdk.java.net/jdk/commit/7c6e3796 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8265120: hs_err improvement: align the output of Virtual space metadata Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3458 From rehn at openjdk.java.net Thu Apr 15 06:47:59 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 15 Apr 2021 06:47:59 GMT Subject: RFR: 8257831: Suspend with handshakes [v4] In-Reply-To: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> References: <_3OlOvuhRPByRWmHYgNn1IxifEPGZhB2AzT3_x_85bk=.96400de6-8269-4814-a452-6bf409ab9b09@github.com> Message-ID: On Fri, 9 Apr 2021 15:39:08 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 six commits: >> >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/objectMonitor.cpp line 410: > >> 408: >> 409: current->frame_anchor()->make_walkable(current); >> 410: OrderAccess::storestore(); > > Needs a comment explaining what the memory sync is for. Missed one, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Thu Apr 15 06:47:56 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 15 Apr 2021 06:47:56 GMT Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 16:05:39 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed flag undef dep + spelling error > > src/hotspot/share/runtime/handshake.hpp line 99: > >> 97: // but we need to check for a safepoint before. >> 98: // (this is due to a suspension handshake which put the JavaThread in blocked >> 99: // state so a safepoint may be in-progress) > > nit: s/(this/(This/ > nit: s/in-progress)/in-progress.)/ Fixed > src/hotspot/share/runtime/handshake.hpp line 166: > >> 164: // thread gets suspended again (after a resume) >> 165: // and we have not yet processed it. >> 166: bool _async_suspend_handshake; > > Does this need to be `volatile`? No, _async_suspend_handshake is now only loaded/stored with mutex held. > src/hotspot/share/runtime/handshake.hpp line 177: > >> 175: void set_suspended(bool to) { return Atomic::store(&_suspended, to); } >> 176: bool has_async_suspend_handshake() { return _async_suspend_handshake; } >> 177: void set_async_suspend_handshake(bool to) { _async_suspend_handshake = to; } > > Does this need to be an Atomic::store? No, _async_suspend_handshake is now only loaded/stored with mutex held. > src/hotspot/share/runtime/objectMonitor.cpp line 424: > >> 422: // thread that suspended us. >> 423: _recursions = 0; >> 424: _succ = NULL; > > You might want to add a comment here: > // Don't need a full fence after clearing successor here because of the call to exit(). Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Thu Apr 15 07:14:09 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 15 Apr 2021 07:14:09 GMT Subject: RFR: 8257831: Suspend with handshakes [v9] In-Reply-To: References: Message-ID: > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'master' into SuspendInHandshake - Review fixes 4 - Fixed flag undef dep + spelling error - Obsolete unused flags - Review fixes 3 - Merge branch 'master' into SuspendInHandshake - Review fixes 2 - White space fixes - Merge branch 'master' into SuspendInHandshake - Review fixes - ... and 3 more: https://git.openjdk.java.net/jdk/compare/b224b566...27bf041c ------------- Changes: https://git.openjdk.java.net/jdk/pull/3191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=08 Stats: 1351 lines in 40 files changed: 273 ins; 882 del; 196 mod Patch: https://git.openjdk.java.net/jdk/pull/3191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191 PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Thu Apr 15 07:14:11 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 15 Apr 2021 07:14:11 GMT Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: <7lr-BFiqmT_Zh6rPM8iawfNEbzkbp16Yq8kW_lx2vvs=.5f41e815-762e-4c76-a758-eca5fbe40f52@github.com> References: <7lr-BFiqmT_Zh6rPM8iawfNEbzkbp16Yq8kW_lx2vvs=.5f41e815-762e-4c76-a758-eca5fbe40f52@github.com> Message-ID: On Wed, 14 Apr 2021 23:11:56 GMT, Serguei Spitsyn wrote: > It looks good. I do not see any serviceability related related issues but posted some nits. > Thanks, > Serguei Thank you Serguei! > src/hotspot/share/prims/jvmtiEnv.cpp line 952: > >> 950: if (!JvmtiSuspendControl::suspend(java_thread)) { >> 951: // Either the thread is already suspended or >> 952: // the thread was in the process of exiting: > > Nit: replace this line with: "// it was in process of exiting." Fixed > src/hotspot/share/prims/jvmtiEnv.cpp line 993: > >> 991: if (!JvmtiSuspendControl::suspend(java_thread)) { >> 992: // Either the thread is already suspended or >> 993: // the thread was in the process of exiting: > > Nit: replace this line with: "// it was in process of exiting." Fixed > src/hotspot/share/prims/jvmtiEnv.cpp line 998: > >> 996: continue; >> 997: } >> 998: results[i] = JVMTI_ERROR_THREAD_SUSPENDED; > > Nit: Remove one extra space after '='. Fixed > src/hotspot/share/prims/jvmtiEnv.cpp line 1006: > >> 1004: if (!JvmtiSuspendControl::suspend(current)) { >> 1005: // Either the thread is already suspended or >> 1006: // the thread was in the process of exiting: > > Nit: replace this line with: "// it was in process of exiting." Fixed > src/hotspot/share/prims/jvmtiEnv.cpp line 1010: > >> 1008: results[self_index] = JVMTI_ERROR_THREAD_NOT_ALIVE; >> 1009: } else { >> 1010: results[self_index] = JVMTI_ERROR_THREAD_SUSPENDED; > > Nit: Remove one extra space after '='. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Thu Apr 15 07:14:14 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 15 Apr 2021 07:14:14 GMT Subject: RFR: 8257831: Suspend with handshakes [v9] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 16:27:10 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 13 commits: >> >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes 4 >> - Fixed flag undef dep + spelling error >> - Obsolete unused flags >> - Review fixes 3 >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes 2 >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/b224b566...27bf041c > > src/hotspot/share/runtime/handshake.cpp line 415: > >> 413: // Adds are done lock free and so is arming. >> 414: // Calling this method with lock held is considered an error. >> 415: assert(!_lock.owned_by_self(), "Lock should not be held"); > > I originally added this comment inside the "resolved" conversation and that kept > this comment from showing up. Let's try it as a new comment. > > Doesn't that mean the comment on L415 needs updating? > Should it be something like: > > // Synchronous adds are done lock free and so is arming, but some > // asynchronous adds are done when we already hold the lock. > > I'm not sure about the "some asynchronous adds" part... > @dcubed-ojdk The mutex is unrelated to adds/inserts. Adds/inserts to the queue can always be done regardless of which locks a thread may or may not have. The reason for not allowing inserts while holding the HandshakeState lock was to eliminate that from the table, since it have other implications. As @pchilano found we needed to reverse the order in should_process() to make it work (which I missed). So now when we have looked at the case, it is okay to do it. Meaning that you can add a handshake to yourself from another handshake regardless of it is sync or async. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Thu Apr 15 07:14:21 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 15 Apr 2021 07:14:21 GMT Subject: RFR: 8257831: Suspend with handshakes [v8] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 16:30:56 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed flag undef dep + spelling error > > src/hotspot/share/runtime/objectMonitor.cpp line 972: > >> 970: >> 971: current->frame_anchor()->make_walkable(current); >> 972: OrderAccess::storestore(); > > Repeating this comment since my original is marked resolved, but I'm not seeing > a new comment here. I originally pointed this out in the resolved conversation, > but that doesn't make the comment show up in the review emails. > > Needs a comment explaining what the memory sync is for. I seem to have fixed 2 of out 3. > src/hotspot/share/runtime/objectMonitor.cpp line 1559: > >> 1557: if (_succ == current) { >> 1558: _succ = NULL; >> 1559: OrderAccess::fence(); > > My original comment is marked "fixed", but I don't see the new comment: > > Please add a comment to this line: > OrderAccess::fence(); // always do a full fence when successor is cleared I fixed the one at line 982, it was not clear there were two from your comment :) Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From hseigel at openjdk.java.net Thu Apr 15 12:22:52 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 15 Apr 2021 12:22:52 GMT Subject: RFR: 8257804 Test runtime/modules/ModuleStress/ModuleStressGC.java fails: 'package test defined in module jdk.test, exports list being walked' missing from stdout/stderr In-Reply-To: <1K82ZDx2FI0xPJS6xNRKxEw_-bXcHBdbmZ1c3PBFMT8=.42faddae-7dca-4532-b7b5-7e802a283f7a@github.com> References: <1K82ZDx2FI0xPJS6xNRKxEw_-bXcHBdbmZ1c3PBFMT8=.42faddae-7dca-4532-b7b5-7e802a283f7a@github.com> Message-ID: On Wed, 14 Apr 2021 18:25:04 GMT, Harold Seigel wrote: > Please review this small test change to reduce the size of the Java heap used by the test so that the test's call to System.gc() is potentially more likely to walk the JVM's module reads-list and exports-list structures. > > The modified test was tested on Linux, Mac OS, and run 1000 times on Windows, where the previous failures had occurred. > > Thanks, Harold Thanks David for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3497 From hseigel at openjdk.java.net Thu Apr 15 12:22:53 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 15 Apr 2021 12:22:53 GMT Subject: Integrated: 8257804 Test runtime/modules/ModuleStress/ModuleStressGC.java fails: 'package test defined in module jdk.test, exports list being walked' missing from stdout/stderr In-Reply-To: <1K82ZDx2FI0xPJS6xNRKxEw_-bXcHBdbmZ1c3PBFMT8=.42faddae-7dca-4532-b7b5-7e802a283f7a@github.com> References: <1K82ZDx2FI0xPJS6xNRKxEw_-bXcHBdbmZ1c3PBFMT8=.42faddae-7dca-4532-b7b5-7e802a283f7a@github.com> Message-ID: <5lctd2qdObJ4bHeHYsILc4dBei3LHrCJoMBrVntPXdA=.b7cbb3e2-9285-481d-a8f4-bc8b1d60d859@github.com> On Wed, 14 Apr 2021 18:25:04 GMT, Harold Seigel wrote: > Please review this small test change to reduce the size of the Java heap used by the test so that the test's call to System.gc() is potentially more likely to walk the JVM's module reads-list and exports-list structures. > > The modified test was tested on Linux, Mac OS, and run 1000 times on Windows, where the previous failures had occurred. > > Thanks, Harold This pull request has now been integrated. Changeset: b23dbdbd Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/b23dbdbd Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod 8257804: Test runtime/modules/ModuleStress/ModuleStressGC.java fails: 'package test defined in module jdk.test, exports list being walked' missing from stdout/stderr Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3497 From mikael at openjdk.java.net Thu Apr 15 15:18:56 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 15 Apr 2021 15:18:56 GMT Subject: RFR: 8265293: ProblemList java/foreign/TestDowncall.java on macosx-aarch64 Message-ID: 8265293: ProblemList java/foreign/TestDowncall.java on macosx-aarch64 ------------- Commit messages: - 8265293: ProblemList java/foreign/TestDowncall.java on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3520/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3520&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265293 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3520.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3520/head:pull/3520 PR: https://git.openjdk.java.net/jdk/pull/3520 From ccheung at openjdk.java.net Thu Apr 15 15:42:35 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 15 Apr 2021 15:42:35 GMT Subject: RFR: 8265293: ProblemList java/foreign/TestDowncall.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 15:12:29 GMT, Mikael Vidstedt wrote: > 8265293: ProblemList java/foreign/TestDowncall.java on macosx-aarch64 Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3520 From dcubed at openjdk.java.net Thu Apr 15 16:15:38 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 15 Apr 2021 16:15:38 GMT Subject: RFR: 8265293: ProblemList java/foreign/TestDowncall.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 15:12:29 GMT, Mikael Vidstedt wrote: > 8265293: ProblemList java/foreign/TestDowncall.java on macosx-aarch64 Thumbs up. This is a trivial fix and does not need to wait 24 hours. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3520 From mikael at openjdk.java.net Thu Apr 15 17:00:37 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 15 Apr 2021 17:00:37 GMT Subject: Integrated: 8265293: ProblemList java/foreign/TestDowncall.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 15:12:29 GMT, Mikael Vidstedt wrote: > 8265293: ProblemList java/foreign/TestDowncall.java on macosx-aarch64 This pull request has now been integrated. Changeset: 838c11fc Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/838c11fc Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8265293: ProblemList java/foreign/TestDowncall.java on macosx-aarch64 Reviewed-by: ccheung, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3520 From dcubed at openjdk.java.net Thu Apr 15 17:05:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 15 Apr 2021 17:05:58 GMT Subject: RFR: 8257831: Suspend with handshakes [v9] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 07:14:09 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'master' into SuspendInHandshake > - Review fixes 4 > - Fixed flag undef dep + spelling error > - Obsolete unused flags > - Review fixes 3 > - Merge branch 'master' into SuspendInHandshake > - Review fixes 2 > - White space fixes > - Merge branch 'master' into SuspendInHandshake > - Review fixes > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/b224b566...27bf041c Reviewed the v08 incremental. Still thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From shade at openjdk.java.net Thu Apr 15 17:13:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Apr 2021 17:13:02 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected Message-ID: I stumbled upon this when doing some Shenandoah work. The development code tried to lock the `leaf` lock, while already holding the `access` lock. Normally it would have been detected by VM, but instead, we tried to recursively acquire `tty_lock` for `Thread::print_owned_locks`. But that `tty` lock is still ranked higher than `access`, so deadlock detection triggers over and over again until we run out of stack and crash hard. `tty` and `access` are ranked this way because of [JDK-8214315](https://bugs.openjdk.java.net/browse/JDK-8214315). Read the rest in the bug. I believe the way out is to only enter `Thread::print_owned_locks` when we know deadlock detection code would not run in circles. New test for `access` and `leaf` shows the original failure. Another new test checks `tty` and `special` to verify that the check should be `> tty`, not `>= tty`. Additional testing: - [ ] Linux x86_64 fastdebug tier1 - [x] New regression tests (fail without the patch, pass wit it) ------------- Commit messages: - JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected Changes: https://git.openjdk.java.net/jdk/pull/3524/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3524&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265298 Stats: 68 lines in 2 files changed: 67 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3524/head:pull/3524 PR: https://git.openjdk.java.net/jdk/pull/3524 From ccheung at openjdk.java.net Thu Apr 15 17:13:34 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 15 Apr 2021 17:13:34 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:14:46 GMT, Calvin Cheung wrote: > Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. > During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. > Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. > > Passed tiers 1,2,3,4 tests on mach5. I've added some performance numbers in the bug report. https://bugs.openjdk.java.net/browse/JDK-8261090?focusedCommentId=14413598&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14413598 ------------- PR: https://git.openjdk.java.net/jdk/pull/3479 From ccheung at openjdk.java.net Thu Apr 15 17:13:36 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 15 Apr 2021 17:13:36 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive In-Reply-To: References: Message-ID: <-XOFxGr03HRkkZLFukSxo4Xk1oEZXlkNYrU3ncVDiZg=.1d0b8a7d-27d6-4b0a-9270-a1f788fee8da@github.com> On Wed, 14 Apr 2021 01:05:27 GMT, Jiangli Zhou wrote: >> Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. >> During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. >> Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. >> >> Passed tiers 1,2,3,4 tests on mach5. > > src/hotspot/share/memory/metaspaceShared.cpp line 759: > >> 757: Thread* THREAD = current; // For exception macros. >> 758: Arguments::assert_is_dumping_archive(); >> 759: if (ik->is_loaded() && !ik->is_linked() && !MetaspaceShared::is_old_class(ik) && > > It would be desirable to support the cases when verification is not enabled, which are not rare. For old classes, bytecode rewriting and class linking can still be done at dump time in those cases, with your current proposed change that includes old classes in the archive image. Otherwise, runtime would have to spend CPU cycles to do rewriting/linking for old classes when not truly necessary. I think that should be done in a separate RFE. It has security implication -- it may not be a good idea to implement a performance feature that you can get only by disabling verification. This will need more community input and security review. What we have implemented in this PR is a compromise -- support old classes in CDS as much as we can, without breaking any security mechanisms. There are also alternatives for further improvement. For example, we can modify the old verifier to store verification constraints in the CDS archive. This will require more work, but will preserve the Java security model. ------------- PR: https://git.openjdk.java.net/jdk/pull/3479 From dcubed at openjdk.java.net Thu Apr 15 17:33:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 15 Apr 2021 17:33:58 GMT Subject: Integrated: 8265302: ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp Message-ID: A trivial fix to ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp. ------------- Commit messages: - 8265302: ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp Changes: https://git.openjdk.java.net/jdk/pull/3525/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3525&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265302 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3525/head:pull/3525 PR: https://git.openjdk.java.net/jdk/pull/3525 From mikael at openjdk.java.net Thu Apr 15 17:33:58 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 15 Apr 2021 17:33:58 GMT Subject: Integrated: 8265302: ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp In-Reply-To: References: Message-ID: <2qJ24ep5dCgvGDB2hp3IDLGDlEUD2dmQGFO-R33W6Og=.f0195c38-0635-43eb-8444-2ed4b1f340fe@github.com> On Thu, 15 Apr 2021 17:23:15 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3525 From dcubed at openjdk.java.net Thu Apr 15 17:33:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 15 Apr 2021 17:33:58 GMT Subject: Integrated: 8265302: ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp In-Reply-To: <2qJ24ep5dCgvGDB2hp3IDLGDlEUD2dmQGFO-R33W6Og=.f0195c38-0635-43eb-8444-2ed4b1f340fe@github.com> References: <2qJ24ep5dCgvGDB2hp3IDLGDlEUD2dmQGFO-R33W6Og=.f0195c38-0635-43eb-8444-2ed4b1f340fe@github.com> Message-ID: On Thu, 15 Apr 2021 17:27:40 GMT, Mikael Vidstedt wrote: >> A trivial fix to ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp. > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the lightning fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3525 From dcubed at openjdk.java.net Thu Apr 15 17:33:59 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 15 Apr 2021 17:33:59 GMT Subject: Integrated: 8265302: ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 17:23:15 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp. This pull request has now been integrated. Changeset: c7da64a4 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/c7da64a4 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8265302: ProblemList runtime/logging/RedefineClasses.java on linux-x64 -Xcomp Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/3525 From pchilanomate at openjdk.java.net Thu Apr 15 19:02:37 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 15 Apr 2021 19:02:37 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 16:56:31 GMT, Aleksey Shipilev wrote: > I stumbled upon this when doing some Shenandoah work. The development code tried to lock the `leaf` lock, while already holding the `access` lock. Normally it would have been detected by VM, but instead, we tried to recursively acquire `tty_lock` for `Thread::print_owned_locks`. But that `tty` lock is still ranked higher than `access`, so deadlock detection triggers over and over again until we run out of stack and crash hard. `tty` and `access` are ranked this way because of [JDK-8214315](https://bugs.openjdk.java.net/browse/JDK-8214315). Read the rest in the bug. > > I believe the way out is to only enter `Thread::print_owned_locks` when we know deadlock detection code would not run in circles. New test for `access` and `leaf` shows the original failure. Another new test checks `tty` and `special` to verify that the check should be `> tty`, not `>= tty`. > > Additional testing: > - [x] Linux x86_64 fastdebug tier1 > - [x] New regression tests (fail without the patch, pass wit it) Hi Aleksey, Fix looks good to me. We could even avoid that print altogether since we already have the offending locks in the assert message, and the hs_err file will show the owners of all locks anyways. But I guess it doesn't hurt to try and print that when we know is safe. Only comments on the added test cases. Thanks, Patricio test/hotspot/gtest/runtime/test_mutex_rank.cpp line 107: > 105: } > 106: > 107: TEST_VM_ASSERT_MSG(MutexRank, mutex_wait_access_leaf, s/mutex_wait/mutex_lock test/hotspot/gtest/runtime/test_mutex_rank.cpp line 122: > 120: } > 121: > 122: TEST_VM_ASSERT_MSG(MutexRank, mutex_wait_tty_special, s/mutex_wait/mutex_lock test/hotspot/gtest/runtime/test_mutex_rank.cpp line 210: > 208: monitor_rank_access->lock_without_safepoint_check(); > 209: monitor_rank_leaf->lock_without_safepoint_check(); > 210: monitor_rank_leaf->wait_without_safepoint_check(1); If you want to exercise the wait() error case you should lock the leaf lock first and then the access one. Then you will get the assert at wait_without_safepoint_check(1). You will have to fix the error message that we check for above to be the one used in the wait case. test/hotspot/gtest/runtime/test_mutex_rank.cpp line 226: > 224: monitor_rank_tty->lock_without_safepoint_check(); > 225: monitor_rank_special->lock_without_safepoint_check(); > 226: monitor_rank_special->wait_without_safepoint_check(1); Same as above, should lock special first and then tty one. ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/3524 From shade at openjdk.java.net Thu Apr 15 19:44:35 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Apr 2021 19:44:35 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 18:44:06 GMT, Patricio Chilano Mateo wrote: >> I stumbled upon this when doing some Shenandoah work. The development code tried to lock the `leaf` lock, while already holding the `access` lock. Normally it would have been detected by VM, but instead, we tried to recursively acquire `tty_lock` for `Thread::print_owned_locks`. But that `tty` lock is still ranked higher than `access`, so deadlock detection triggers over and over again until we run out of stack and crash hard. `tty` and `access` are ranked this way because of [JDK-8214315](https://bugs.openjdk.java.net/browse/JDK-8214315). Read the rest in the bug. >> >> I believe the way out is to only enter `Thread::print_owned_locks` when we know deadlock detection code would not run in circles. New test for `access` and `leaf` shows the original failure. Another new test checks `tty` and `special` to verify that the check should be `> tty`, not `>= tty`. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug tier1 >> - [x] New regression tests (fail without the patch, pass wit it) > > test/hotspot/gtest/runtime/test_mutex_rank.cpp line 210: > >> 208: monitor_rank_access->lock_without_safepoint_check(); >> 209: monitor_rank_leaf->lock_without_safepoint_check(); >> 210: monitor_rank_leaf->wait_without_safepoint_check(1); > > If you want to exercise the wait() error case you should lock the leaf lock first and then the access one. Then you will get the assert at wait_without_safepoint_check(1). You will have to fix the error message that we check for above to be the one used in the wait case. The intent is to lock `access` first, then `leaf` -- after all, that was the issue I initially found. About `wait`: I copy-pasted the shape of the test from the `monitor_wait_rank_special` above. I thought it was dubious that we basically expect to assert at `monitor_rank_leaf->lock_without_safepoint_check();`, but thought having `wait` makes the code a bit more readable. I can just remove `wait` here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From shade at openjdk.java.net Thu Apr 15 19:47:32 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Apr 2021 19:47:32 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 19:41:41 GMT, Aleksey Shipilev wrote: >> test/hotspot/gtest/runtime/test_mutex_rank.cpp line 210: >> >>> 208: monitor_rank_access->lock_without_safepoint_check(); >>> 209: monitor_rank_leaf->lock_without_safepoint_check(); >>> 210: monitor_rank_leaf->wait_without_safepoint_check(1); >> >> If you want to exercise the wait() error case you should lock the leaf lock first and then the access one. Then you will get the assert at wait_without_safepoint_check(1). You will have to fix the error message that we check for above to be the one used in the wait case. > > The intent is to lock `access` first, then `leaf` -- after all, that was the issue I initially found. About `wait`: I copy-pasted the shape of the test from the `monitor_wait_rank_special` above. I thought it was dubious that we basically expect to assert at `monitor_rank_leaf->lock_without_safepoint_check();`, but thought having `wait` makes the code a bit more readable. I can just remove `wait` here. Ah, you mean the test checks the attempt to wait! Right, let me fix that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From xliu at openjdk.java.net Thu Apr 15 19:52:35 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 15 Apr 2021 19:52:35 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 16:56:31 GMT, Aleksey Shipilev wrote: > I stumbled upon this when doing some Shenandoah work. The development code tried to lock the `leaf` lock, while already holding the `access` lock. Normally it would have been detected by VM, but instead, we tried to recursively acquire `tty_lock` for `Thread::print_owned_locks`. But that `tty` lock is still ranked higher than `access`, so deadlock detection triggers over and over again until we run out of stack and crash hard. `tty` and `access` are ranked this way because of [JDK-8214315](https://bugs.openjdk.java.net/browse/JDK-8214315). Read the rest in the bug. > > I believe the way out is to only enter `Thread::print_owned_locks` when we know deadlock detection code would not run in circles. New test for `access` and `leaf` shows the original failure. Another new test checks `tty` and `special` to verify that the check should be `> tty`, not `>= tty`. > > Additional testing: > - [x] Linux x86_64 fastdebug tier1 > - [x] New regression tests (fail without the patch, pass wit it) src/hotspot/share/runtime/mutex.cpp line 416: > 414: if (least != NULL && least->rank() <= this->rank()) { > 415: if (least->rank() > Mutex::tty) { > 416: // Printing owned locks acquires tty lock. If lowest rank is below or equal If the least* rank was* below or equal tty, ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From shade at openjdk.java.net Thu Apr 15 19:52:36 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Apr 2021 19:52:36 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected In-Reply-To: References: Message-ID: <7xm28-h99jdvbjbCLKQgbPotdmvPPhAIo9LkLgXMr7w=.5d3623b2-4ca5-4d37-98af-7817558e9a43@github.com> On Thu, 15 Apr 2021 18:37:33 GMT, Patricio Chilano Mateo wrote: >> I stumbled upon this when doing some Shenandoah work. The development code tried to lock the `leaf` lock, while already holding the `access` lock. Normally it would have been detected by VM, but instead, we tried to recursively acquire `tty_lock` for `Thread::print_owned_locks`. But that `tty` lock is still ranked higher than `access`, so deadlock detection triggers over and over again until we run out of stack and crash hard. `tty` and `access` are ranked this way because of [JDK-8214315](https://bugs.openjdk.java.net/browse/JDK-8214315). Read the rest in the bug. >> >> I believe the way out is to only enter `Thread::print_owned_locks` when we know deadlock detection code would not run in circles. New test for `access` and `leaf` shows the original failure. Another new test checks `tty` and `special` to verify that the check should be `> tty`, not `>= tty`. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug tier1 >> - [x] New regression tests (fail without the patch, pass wit it) > > test/hotspot/gtest/runtime/test_mutex_rank.cpp line 107: > >> 105: } >> 106: >> 107: TEST_VM_ASSERT_MSG(MutexRank, mutex_wait_access_leaf, > > s/mutex_wait/mutex_lock Renamed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From xliu at openjdk.java.net Thu Apr 15 19:52:36 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 15 Apr 2021 19:52:36 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected In-Reply-To: <7xm28-h99jdvbjbCLKQgbPotdmvPPhAIo9LkLgXMr7w=.5d3623b2-4ca5-4d37-98af-7817558e9a43@github.com> References: <7xm28-h99jdvbjbCLKQgbPotdmvPPhAIo9LkLgXMr7w=.5d3623b2-4ca5-4d37-98af-7817558e9a43@github.com> Message-ID: On Thu, 15 Apr 2021 19:48:45 GMT, Aleksey Shipilev wrote: >> test/hotspot/gtest/runtime/test_mutex_rank.cpp line 107: >> >>> 105: } >>> 106: >>> 107: TEST_VM_ASSERT_MSG(MutexRank, mutex_wait_access_leaf, >> >> s/mutex_wait/mutex_lock > > Renamed. +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From shade at openjdk.java.net Thu Apr 15 20:01:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Apr 2021 20:01:09 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected [v2] In-Reply-To: References: Message-ID: > I stumbled upon this when doing some Shenandoah work. The development code tried to lock the `leaf` lock, while already holding the `access` lock. Normally it would have been detected by VM, but instead, we tried to recursively acquire `tty_lock` for `Thread::print_owned_locks`. But that `tty` lock is still ranked higher than `access`, so deadlock detection triggers over and over again until we run out of stack and crash hard. `tty` and `access` are ranked this way because of [JDK-8214315](https://bugs.openjdk.java.net/browse/JDK-8214315). Read the rest in the bug. > > I believe the way out is to only enter `Thread::print_owned_locks` when we know deadlock detection code would not run in circles. New test for `access` and `leaf` shows the original failure. Another new test checks `tty` and `special` to verify that the check should be `> tty`, not `>= tty`. > > Additional testing: > - [x] Linux x86_64 fastdebug tier1 > - [x] New regression tests (fail without the patch, pass wit it) Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Patricio's review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3524/files - new: https://git.openjdk.java.net/jdk/pull/3524/files/ecf6e5bb..7c4410df Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3524&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3524&range=00-01 Stats: 19 lines in 1 file changed: 5 ins; 5 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3524/head:pull/3524 PR: https://git.openjdk.java.net/jdk/pull/3524 From xliu at openjdk.java.net Thu Apr 15 20:01:09 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 15 Apr 2021 20:01:09 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 16:56:31 GMT, Aleksey Shipilev wrote: > I stumbled upon this when doing some Shenandoah work. The development code tried to lock the `leaf` lock, while already holding the `access` lock. Normally it would have been detected by VM, but instead, we tried to recursively acquire `tty_lock` for `Thread::print_owned_locks`. But that `tty` lock is still ranked higher than `access`, so deadlock detection triggers over and over again until we run out of stack and crash hard. `tty` and `access` are ranked this way because of [JDK-8214315](https://bugs.openjdk.java.net/browse/JDK-8214315). Read the rest in the bug. > > I believe the way out is to only enter `Thread::print_owned_locks` when we know deadlock detection code would not run in circles. New test for `access` and `leaf` shows the original failure. Another new test checks `tty` and `special` to verify that the check should be `> tty`, not `>= tty`. > > Additional testing: > - [x] Linux x86_64 fastdebug tier1 > - [x] New regression tests (fail without the patch, pass wit it) hi, Aleksey, Thank you for fixing this issue. I ran into it too! Your fix looks reasonable to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From shade at openjdk.java.net Thu Apr 15 20:01:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Apr 2021 20:01:10 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected [v2] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 19:45:00 GMT, Aleksey Shipilev wrote: >> The intent is to lock `access` first, then `leaf` -- after all, that was the issue I initially found. About `wait`: I copy-pasted the shape of the test from the `monitor_wait_rank_special` above. I thought it was dubious that we basically expect to assert at `monitor_rank_leaf->lock_without_safepoint_check();`, but thought having `wait` makes the code a bit more readable. I can just remove `wait` here. > > Ah, you mean the test checks the attempt to wait! Right, let me fix that. Fixed. There is a wrinkle: `leaf` is not a `special` lock, so this test would make little sense. I replaced `leaf` with `tty` instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From shade at openjdk.java.net Thu Apr 15 20:01:11 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Apr 2021 20:01:11 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected [v2] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 18:59:17 GMT, Patricio Chilano Mateo wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Patricio's review > > test/hotspot/gtest/runtime/test_mutex_rank.cpp line 226: > >> 224: monitor_rank_tty->lock_without_safepoint_check(); >> 225: monitor_rank_special->lock_without_safepoint_check(); >> 226: monitor_rank_special->wait_without_safepoint_check(1); > > Same as above, should lock special first and then tty one. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From shade at openjdk.java.net Thu Apr 15 20:12:48 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Apr 2021 20:12:48 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected [v3] In-Reply-To: References: Message-ID: > I stumbled upon this when doing some Shenandoah work. The development code tried to lock the `leaf` lock, while already holding the `access` lock. Normally it would have been detected by VM, but instead, we tried to recursively acquire `tty_lock` for `Thread::print_owned_locks`. But that `tty` lock is still ranked higher than `access`, so deadlock detection triggers over and over again until we run out of stack and crash hard. `tty` and `access` are ranked this way because of [JDK-8214315](https://bugs.openjdk.java.net/browse/JDK-8214315). Read the rest in the bug. > > I believe the way out is to only enter `Thread::print_owned_locks` when we know deadlock detection code would not run in circles. New test for `access` and `leaf` shows the original failure. Another new test checks `tty` and `special` to verify that the check should be `> tty`, not `>= tty`. > > Additional testing: > - [x] Linux x86_64 fastdebug tier1 > - [x] New regression tests (fail without the patch, pass wit it) Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Polish a comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3524/files - new: https://git.openjdk.java.net/jdk/pull/3524/files/7c4410df..5a36e076 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3524&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3524&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3524/head:pull/3524 PR: https://git.openjdk.java.net/jdk/pull/3524 From shade at openjdk.java.net Thu Apr 15 20:12:49 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Apr 2021 20:12:49 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected [v3] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 19:49:31 GMT, Xin Liu wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Polish a comment > > src/hotspot/share/runtime/mutex.cpp line 416: > >> 414: if (least != NULL && least->rank() <= this->rank()) { >> 415: if (least->rank() > Mutex::tty) { >> 416: // Printing owned locks acquires tty lock. If lowest rank is below or equal > > If the least* rank was* below or equal tty, Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From pchilanomate at openjdk.java.net Thu Apr 15 20:39:38 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 15 Apr 2021 20:39:38 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected [v3] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 20:12:48 GMT, Aleksey Shipilev wrote: >> I stumbled upon this when doing some Shenandoah work. The development code tried to lock the `leaf` lock, while already holding the `access` lock. Normally it would have been detected by VM, but instead, we tried to recursively acquire `tty_lock` for `Thread::print_owned_locks`. But that `tty` lock is still ranked higher than `access`, so deadlock detection triggers over and over again until we run out of stack and crash hard. `tty` and `access` are ranked this way because of [JDK-8214315](https://bugs.openjdk.java.net/browse/JDK-8214315). Read the rest in the bug. >> >> I believe the way out is to only enter `Thread::print_owned_locks` when we know deadlock detection code would not run in circles. New test for `access` and `leaf` shows the original failure. Another new test checks `tty` and `special` to verify that the check should be `> tty`, not `>= tty`. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug tier1 >> - [x] New regression tests (fail without the patch, pass wit it) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Polish a comment Thanks Aleksey, fixes look good! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From pchilanomate at openjdk.java.net Thu Apr 15 20:39:38 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 15 Apr 2021 20:39:38 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected [v3] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 19:56:03 GMT, Aleksey Shipilev wrote: >> Ah, you mean the test checks the attempt to wait! Right, let me fix that. > > Fixed. There is a wrinkle: `leaf` is not a `special` lock, so this test would make little sense. I replaced `leaf` with `tty` instead. Fix looks good. I thought you wanted to check the other failure mode in wait() (the one where you have to wait on the least rank owned monitor). ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From dholmes at openjdk.java.net Thu Apr 15 22:19:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Apr 2021 22:19:37 GMT Subject: RFR: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected [v3] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 20:12:48 GMT, Aleksey Shipilev wrote: >> I stumbled upon this when doing some Shenandoah work. The development code tried to lock the `leaf` lock, while already holding the `access` lock. Normally it would have been detected by VM, but instead, we tried to recursively acquire `tty_lock` for `Thread::print_owned_locks`. But that `tty` lock is still ranked higher than `access`, so deadlock detection triggers over and over again until we run out of stack and crash hard. `tty` and `access` are ranked this way because of [JDK-8214315](https://bugs.openjdk.java.net/browse/JDK-8214315). Read the rest in the bug. >> >> I believe the way out is to only enter `Thread::print_owned_locks` when we know deadlock detection code would not run in circles. New test for `access` and `leaf` shows the original failure. Another new test checks `tty` and `special` to verify that the check should be `> tty`, not `>= tty`. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug tier1 >> - [x] New regression tests (fail without the patch, pass wit it) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Polish a comment Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3524 From dholmes at openjdk.java.net Thu Apr 15 22:27:01 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Apr 2021 22:27:01 GMT Subject: RFR: 8257831: Suspend with handshakes [v9] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 07:14:09 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'master' into SuspendInHandshake > - Review fixes 4 > - Fixed flag undef dep + spelling error > - Obsolete unused flags > - Review fixes 3 > - Merge branch 'master' into SuspendInHandshake > - Review fixes 2 > - White space fixes > - Merge branch 'master' into SuspendInHandshake > - Review fixes > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/b224b566...27bf041c Only nits on the incremental. Like Dan I need to re-examine the complete set of changes to see if anything else sticks out (other than the non-encapsulation of the state changes around locking/unlocking when suspended). Thanks, David src/hotspot/share/prims/jvmtiEnv.cpp line 952: > 950: if (!JvmtiSuspendControl::suspend(java_thread)) { > 951: // Either the thread is already suspended or > 952: // it was in process of exiting. Nit: the previous comment was perfectly correct. It is okay to replace the second "the thread" with "it" but it should still read "in _the_ process of exiting". src/hotspot/share/prims/jvmtiEnv.cpp line 993: > 991: if (!JvmtiSuspendControl::suspend(java_thread)) { > 992: // Either the thread is already suspended or > 993: // it was in process of exiting. Ditto - "in the process ..." src/hotspot/share/prims/jvmtiEnv.cpp line 1006: > 1004: if (!JvmtiSuspendControl::suspend(current)) { > 1005: // Either the thread is already suspended or > 1006: // it was in process of exiting. Ditto - "in the process ..." ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From github.com+22177208+aostrouhhov at openjdk.java.net Thu Apr 15 23:56:55 2021 From: github.com+22177208+aostrouhhov at openjdk.java.net (Anton Ostrouhhov) Date: Thu, 15 Apr 2021 23:56:55 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled Message-ID: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> Hello! Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`. This is my first contribution so please tell me if i am wrong somewhere. ------------- Commit messages: - 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled Changes: https://git.openjdk.java.net/jdk/pull/3206/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3206&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262953 Stats: 14 lines in 1 file changed: 13 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3206.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3206/head:pull/3206 PR: https://git.openjdk.java.net/jdk/pull/3206 From dholmes at openjdk.java.net Fri Apr 16 01:15:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Apr 2021 01:15:37 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> Message-ID: <0cG6VLyzhaiGTBnFDCo5nUpuATN5SYoWjFmP6CFHP1M=.9f70ab56-6306-4fef-b996-3b6f72df8494@github.com> On Thu, 25 Mar 2021 20:11:30 GMT, Anton Ostrouhhov wrote: > Hello! > Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`. > > This is my first contribution so please tell me if i am wrong somewhere. Hi Anton, Your change certainly fixes the test, but I have to wonder whether the real problem isn't that our cgroup code should handle this case better and still report the "not available" value rather than skipping it completely? @jerboaa and @YaSuenag what are your thoughts? Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From vromero at openjdk.java.net Fri Apr 16 01:15:58 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 16 Apr 2021 01:15:58 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature Message-ID: Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Thanks ------------- Commit messages: - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - 8260517: Compiler implementation for Sealed Classes Changes: https://git.openjdk.java.net/jdk/pull/3526/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260517 Stats: 450 lines in 56 files changed: 48 ins; 282 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From dholmes at openjdk.java.net Fri Apr 16 01:42:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Apr 2021 01:42:55 GMT Subject: RFR: 8265314: Obsolete the unused AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags Message-ID: The AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags became unused with the changes in JDK-8223312 and should have been obsoleted then. Thanks, David ------------- Commit messages: - 8265314: Obsolete the unused AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags Changes: https://git.openjdk.java.net/jdk/pull/3527/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3527&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265314 Stats: 8 lines in 2 files changed: 2 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3527.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3527/head:pull/3527 PR: https://git.openjdk.java.net/jdk/pull/3527 From dholmes at openjdk.java.net Fri Apr 16 02:14:02 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Apr 2021 02:14:02 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v2] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 02:11:10 GMT, Vicente Romero wrote: >> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) >> >> Thanks >> >> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > removing javax.lang.model changes Hi Vincente, Hotspot and hotspot tests all look fine. One query: why was this test removed? test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java is that functionality tested elsewhere? (The other deleted test seemed obviously trivial.) Thanks, David src/hotspot/share/classfile/classFileParser.cpp line 3916: > 3914: record_attribute_start = cfs->current(); > 3915: record_attribute_length = attribute_length; > 3916: } else if (_major_version >= JAVA_17_VERSION) { Can you update the comment at L3932 to say JAVA_17_VERSION please. src/hotspot/share/classfile/classFileParser.hpp line 345: > 343: > 344: bool supports_sealed_types(); > 345: bool supports_records(); Good catch! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3526 From vromero at openjdk.java.net Fri Apr 16 02:14:01 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 16 Apr 2021 02:14:01 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v2] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing javax.lang.model changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/6e2a99c6..5aef5108 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=00-01 Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From ysuenaga at openjdk.java.net Fri Apr 16 02:28:35 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 16 Apr 2021 02:28:35 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> Message-ID: <7NdGK5RgmmF8QHJ3ViVRKnSQVQK-AVmE_igqoj8d4gk=.18b4db5f-aaf6-4c7d-9d82-606fe5f3ad58@github.com> On Thu, 25 Mar 2021 20:11:30 GMT, Anton Ostrouhhov wrote: > Hello! > Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`. > > This is my first contribution so please tell me if i am wrong somewhere. I agree with David, I think we should throw SkipException in this case. OTOH this test can catch incorrect behavior if HotSpot could not get CPU related values from cgroups even if `CONFIG_CFS_BANDWIDTH` is configured. So I suggest to check `/boot/config-` in start of the test rather than throwing SkipException. If we cannot see `CONFIG_CFS_BANDWIDTH=y` in it, then we can throw SkipException. ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From david.holmes at oracle.com Fri Apr 16 02:32:40 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Apr 2021 12:32:40 +1000 Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <7NdGK5RgmmF8QHJ3ViVRKnSQVQK-AVmE_igqoj8d4gk=.18b4db5f-aaf6-4c7d-9d82-606fe5f3ad58@github.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> <7NdGK5RgmmF8QHJ3ViVRKnSQVQK-AVmE_igqoj8d4gk=.18b4db5f-aaf6-4c7d-9d82-606fe5f3ad58@github.com> Message-ID: <17d4d8ba-5fd9-02d0-853e-aad03377485a@oracle.com> On 16/04/2021 12:28 pm, Yasumasa Suenaga wrote: > On Thu, 25 Mar 2021 20:11:30 GMT, Anton Ostrouhhov wrote: > >> Hello! >> Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`. >> >> This is my first contribution so please tell me if i am wrong somewhere. > > I agree with David, I think we should throw SkipException in this case. That is not at all what I was suggesting. :) Rather than fixing the test I think our cgroup support code needs to be updated to account for this situation. David > OTOH this test can catch incorrect behavior if HotSpot could not get CPU related values from cgroups even if `CONFIG_CFS_BANDWIDTH` is configured. So I suggest to check `/boot/config-` in start of the test rather than throwing SkipException. If we cannot see `CONFIG_CFS_BANDWIDTH=y` in it, then we can throw SkipException. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3206 > From yyang at openjdk.java.net Fri Apr 16 03:17:56 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 16 Apr 2021 03:17:56 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp Message-ID: Remove unnecessary inclusion of bytecodeHistogram.hpp ------------- Commit messages: - reduce unnecessary include Changes: https://git.openjdk.java.net/jdk/pull/3530/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3530&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265285 Stats: 5 lines in 5 files changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3530/head:pull/3530 PR: https://git.openjdk.java.net/jdk/pull/3530 From vromero at openjdk.java.net Fri Apr 16 03:26:34 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 16 Apr 2021 03:26:34 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v2] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 02:10:05 GMT, David Holmes wrote: > Hi Vicente, > > Hotspot and hotspot tests all look fine. One query: why was this test removed? > > test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java > > is that functionality tested elsewhere? (The other deleted test seemed obviously trivial.) > > Thanks, > David Hi David, thanks for your comments, yes regarding `test test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java`, it was removed because the functionality is tested in `test/langtools/tools/javac/sealed/SealedCompilationTests.java` > src/hotspot/share/classfile/classFileParser.cpp line 3916: > >> 3914: record_attribute_start = cfs->current(); >> 3915: record_attribute_length = attribute_length; >> 3916: } else if (_major_version >= JAVA_17_VERSION) { > > Can you update the comment at L3932 to say JAVA_17_VERSION please. sure ------------- PR: https://git.openjdk.java.net/jdk/pull/3526 From vromero at openjdk.java.net Fri Apr 16 03:35:06 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 16 Apr 2021 03:35:06 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v3] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: updating comment after review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/5aef5108..8ebe56fd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From ysuenaga at openjdk.java.net Fri Apr 16 04:18:40 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 16 Apr 2021 04:18:40 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <17d4d8ba-5fd9-02d0-853e-aad03377485a@oracle.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> <17d4d8ba-5fd9-02d0-853e-aad03377485a@oracle.com> Message-ID: <2LM5mNPaSVP3_2N12tqoV8VNslRSY3EW2dbRJOeBQ3s=.cdd63f54-bf9a-4e31-b2b7-254a805f2618@github.com> On Fri, 16 Apr 2021 02:34:13 GMT, David Holmes wrote: > > I agree with David, I think we should throw SkipException in this case. > > That is not at all what I was suggesting. :) Rather than fixing the test > I think our cgroup support code needs to be updated to account for this > situation. Yeah, it is much better if we can improve cgroups support code! I think it will work on [JDK-8261242](https://bugs.openjdk.java.net/browse/JDK-8261242), but it does not seem to active. In addition we also need to consider about JMX like [JDK-8265104](https://bugs.openjdk.java.net/browse/JDK-8265104) (PR #3447 ). ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From iklam at openjdk.java.net Fri Apr 16 04:36:34 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 16 Apr 2021 04:36:34 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 03:08:22 GMT, Yi Yang wrote: > Remove unnecessary inclusion of bytecodeHistogram.hpp Looks like these files refer to `(BytecodeCounter)|(BytecodeHistogram)(BytecodePairHistogram)` but are missing the inclusion of bytecodeHistogram.hpp - cpu/aarch64/macroAssembler_aarch64.cpp - cpu/arm/macroAssembler_arm.cpp - cpu/x86/macroAssembler_x86.cpp See https://github.com/iklam/tools/blob/main/headers/find_include_problems.sh The problems can usually be found by building without precompiled headers. ------------- PR: https://git.openjdk.java.net/jdk/pull/3530 From david.holmes at oracle.com Fri Apr 16 05:24:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Apr 2021 15:24:03 +1000 Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <2LM5mNPaSVP3_2N12tqoV8VNslRSY3EW2dbRJOeBQ3s=.cdd63f54-bf9a-4e31-b2b7-254a805f2618@github.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> <17d4d8ba-5fd9-02d0-853e-aad03377485a@oracle.com> <2LM5mNPaSVP3_2N12tqoV8VNslRSY3EW2dbRJOeBQ3s=.cdd63f54-bf9a-4e31-b2b7-254a805f2618@github.com> Message-ID: <269a9d25-381d-7671-e127-368e307fc401@oracle.com> On 16/04/2021 2:18 pm, Yasumasa Suenaga wrote: > On Fri, 16 Apr 2021 02:34:13 GMT, David Holmes wrote: > >>> I agree with David, I think we should throw SkipException in this case. >> >> That is not at all what I was suggesting. :) Rather than fixing the test >> I think our cgroup support code needs to be updated to account for this >> situation. > > Yeah, it is much better if we can improve cgroups support code! I think it will work on [JDK-8261242](https://bugs.openjdk.java.net/browse/JDK-8261242), but it does not seem to active. > In addition we also need to consider about JMX like [JDK-8265104](https://bugs.openjdk.java.net/browse/JDK-8265104) (PR #3447 ). I was thinking more simply that callers to ./os/linux/cgroupSubsystem_linux.hpp:#define GET_CONTAINER_INFO should not be so quick to ignore things when it returns OSCONTAINER_ERROR, but should instead report the defined "not present" values. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3206 > From yyang at openjdk.java.net Fri Apr 16 05:24:35 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 16 Apr 2021 05:24:35 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 04:33:14 GMT, Ioi Lam wrote: > Looks like these files refer to `(BytecodeCounter)|(BytecodeHistogram)(BytecodePairHistogram)` but are missing the inclusion of bytecodeHistogram.hpp > > * cpu/aarch64/macroAssembler_aarch64.cpp > * cpu/arm/macroAssembler_arm.cpp > * cpu/x86/macroAssembler_x86.cpp > > See https://github.com/iklam/tools/blob/main/headers/find_include_problems.sh > > The problems can usually be found by building without precompiled headers. Yes, the inclusion of bytecodeHistogram.hpp in sharedRuntime.hpp should remain, others are really unnecessary.(Build without precompile header) ------------- PR: https://git.openjdk.java.net/jdk/pull/3530 From yyang at openjdk.java.net Fri Apr 16 05:28:59 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 16 Apr 2021 05:28:59 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp [v2] In-Reply-To: References: Message-ID: > Remove unnecessary inclusion of bytecodeHistogram.hpp Yi Yang has updated the pull request incrementally with one additional commit since the last revision: remain the inclusion of bytecodeHistogram.hpp in sharedRuntime.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3530/files - new: https://git.openjdk.java.net/jdk/pull/3530/files/37ee2149..a9f01b76 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3530&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3530&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3530/head:pull/3530 PR: https://git.openjdk.java.net/jdk/pull/3530 From dholmes at openjdk.java.net Fri Apr 16 05:37:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Apr 2021 05:37:34 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp [v2] In-Reply-To: References: Message-ID: <1MBFA3SVPw0kicAwbVPBChnM0xPcbe2R-4vY-tWnycA=.196d5e34-964e-43f3-afda-404a50a02789@github.com> On Fri, 16 Apr 2021 05:28:59 GMT, Yi Yang wrote: >> Remove unnecessary inclusion of bytecodeHistogram.hpp > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > remain the inclusion of bytecodeHistogram.hpp in sharedRuntime.hpp Seems okay. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3530 From iklam at openjdk.java.net Fri Apr 16 06:22:33 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 16 Apr 2021 06:22:33 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 05:21:39 GMT, Yi Yang wrote: > > Looks like these files refer to `(BytecodeCounter)|(BytecodeHistogram)(BytecodePairHistogram)` but are missing the inclusion of bytecodeHistogram.hpp > > > > * cpu/aarch64/macroAssembler_aarch64.cpp > > * cpu/arm/macroAssembler_arm.cpp > > * cpu/x86/macroAssembler_x86.cpp > > > > See https://github.com/iklam/tools/blob/main/headers/find_include_problems.sh > > The problems can usually be found by building without precompiled headers. > > Yes, the inclusion of bytecodeHistogram.hpp in sharedRuntime.hpp should remain, others are really unnecessary.(Build without precompile header) sharedRuntime.hpp does not need to include bytecodeHistogram.hpp, since it doesn't use any of the 3 classes declared in bytecodeHistogram.hpp. You should add bytecodeHistogram.hpp to the 3 files I listed above instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/3530 From yyang at openjdk.java.net Fri Apr 16 06:29:33 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 16 Apr 2021 06:29:33 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 06:18:46 GMT, Ioi Lam wrote: > > > Looks like these files refer to `(BytecodeCounter)|(BytecodeHistogram)(BytecodePairHistogram)` but are missing the inclusion of bytecodeHistogram.hpp > > > > > > * cpu/aarch64/macroAssembler_aarch64.cpp > > > * cpu/arm/macroAssembler_arm.cpp > > > * cpu/x86/macroAssembler_x86.cpp > > > > > > See https://github.com/iklam/tools/blob/main/headers/find_include_problems.sh > > > The problems can usually be found by building without precompiled headers. > > > > > > Yes, the inclusion of bytecodeHistogram.hpp in sharedRuntime.hpp should remain, others are really unnecessary.(Build without precompile header) > > sharedRuntime.hpp does not need to include bytecodeHistogram.hpp, since it doesn't use any of the 3 classes declared in bytecodeHistogram.hpp. You should add bytecodeHistogram.hpp to the 3 files I listed above instead. It's indeed more reasonable but needs more changes, I will try to tweak this later. > Seems okay. > > Thanks, > David Thank you David! ------------- PR: https://git.openjdk.java.net/jdk/pull/3530 From rehn at openjdk.java.net Fri Apr 16 06:44:06 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 16 Apr 2021 06:44:06 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Fixed nits ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3191/files - new: https://git.openjdk.java.net/jdk/pull/3191/files/27bf041c..d6e091da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191 PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Fri Apr 16 06:44:08 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 16 Apr 2021 06:44:08 GMT Subject: RFR: 8257831: Suspend with handshakes [v9] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 22:22:53 GMT, David Holmes wrote: > Only nits on the incremental. > > Like Dan I need to re-examine the complete set of changes to see if anything else sticks out (other than the non-encapsulation of the state changes around locking/unlocking when suspended). > > Thanks, > David Yes please. Robbin > src/hotspot/share/prims/jvmtiEnv.cpp line 952: > >> 950: if (!JvmtiSuspendControl::suspend(java_thread)) { >> 951: // Either the thread is already suspended or >> 952: // it was in process of exiting. > > Nit: the previous comment was perfectly correct. It is okay to replace the second "the thread" with "it" but it should still read "in _the_ process of exiting". Fixed > src/hotspot/share/prims/jvmtiEnv.cpp line 993: > >> 991: if (!JvmtiSuspendControl::suspend(java_thread)) { >> 992: // Either the thread is already suspended or >> 993: // it was in process of exiting. > > Ditto - "in the process ..." Fixed > src/hotspot/share/prims/jvmtiEnv.cpp line 1006: > >> 1004: if (!JvmtiSuspendControl::suspend(current)) { >> 1005: // Either the thread is already suspended or >> 1006: // it was in process of exiting. > > Ditto - "in the process ..." Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Fri Apr 16 06:44:08 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 16 Apr 2021 06:44:08 GMT Subject: RFR: 8257831: Suspend with handshakes [v9] In-Reply-To: References: Message-ID: <7_ieDC5PBhv0Xnc18l7N3ODNVvZcdPtAhq56wnTL5Xw=.9017a11d-96da-4354-bd64-0011a1d58659@github.com> On Thu, 15 Apr 2021 17:02:22 GMT, Daniel D. Daugherty wrote: > Reviewed the v08 incremental. Still thumbs up. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From ysuenaga at openjdk.java.net Fri Apr 16 07:18:34 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 16 Apr 2021 07:18:34 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> Message-ID: On Thu, 25 Mar 2021 20:11:30 GMT, Anton Ostrouhhov wrote: > Hello! > Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`. > > This is my first contribution so please tell me if i am wrong somewhere. Hmm... I don't like it because it looks like ad hoc to me. Do similar issues happen in other place? e.g. `GET_CONTAINER_INFO_LINE`. I worried HotSpot has similar issues. We've seen some issues that container support in HotSpot is not enough.IMHO we should separate cgroups and container support in both HotSpot and JMX cleanly, then we should improve cgroups support. I think we can just fix the test until then. ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From shade at openjdk.java.net Fri Apr 16 07:50:35 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 16 Apr 2021 07:50:35 GMT Subject: RFR: 8265314: Obsolete the unused AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags In-Reply-To: References: Message-ID: <7at-d9Ddqslrgn3hQ2nLcfu9YZuuxghg5OyUOVqliBU=.1c6c4854-b710-458b-9419-47579fbc2c60@github.com> On Fri, 16 Apr 2021 01:35:12 GMT, David Holmes wrote: > The AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags became unused with the changes in JDK-8223312 and should have been obsoleted then. > > Thanks, > David This looks fine. But I think this PR mistakenly references the CSR itself, rather than the implementation (JDK-8265313), which is why bots complain. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3527 From shade at openjdk.java.net Fri Apr 16 08:01:38 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 16 Apr 2021 08:01:38 GMT Subject: RFR: JDK-8262165: NMT report should state how many callsites had been skipped In-Reply-To: References: Message-ID: <81Sy_MiX7NUCJdTWGK52nN-GCKIIt7tqXWAHY7i3sXY=.70c19c1c-a7be-408b-8d8f-23fb1930192b@github.com> On Tue, 23 Feb 2021 07:12:10 GMT, Thomas Stuefe wrote: > (This is a breakout from JDK-8261238, which seems to be stuck in review (https://github.com/openjdk/jdk/pull/2428). I factor out the display changes, which hopefully are non-controversial enough to get upstream easily.) > > NMT silently omits call sites in its report whose allocation rate is too small to get over certain, hidden, thresholds: > a) there is a hard wired threshold of 1K in the baseline collector > b) we also skip all sites whose size is less than what the unit is (eg scale=G, we skip all allocations < 1G > > NMT report should state how many call sites had been omitted. > > ---- > > The patch adds a counter in the NMT reporter to count omitted call sites, then prints that counter out. > > In base report, just a generic message is shown to notify the user that categories > scale are ignored: > > > thomas at mainframe$ jcmd Interl VM.native_memory scale=m > 2847: > > Native Memory Tracking: > > (Omitting categories weighting less than 1MB) > > Total: reserved=5540MB, committed=147MB > - Java Heap (reserved=3996MB, committed=34MB) > (mmap: reserved=3996MB, committed=34MB) > > > > In detail report, the total count of omitted call sites is displayed at the bottom: > > > thomas at mainframe$ jcmd Interl VM.native_memory scale=m detail > 2847: > > > > [0x00007f4e062e3e6b] os::reserve_memory(unsigned long, bool, MEMFLAGS)+0x16b > [0x00007f4e05ac4f47] MmapArrayAllocator::allocate(unsigned long, MEMFLAGS)+0x127 > [0x00007f4e05ac4cb2] G1FromCardCache::initialize(unsigned int)+0xe2 > [0x00007f4e05a863f1] G1CollectedHeap::initialize()+0x3c1 > (reserved=1MB, committed=1MB Type=GC) > > (183 call sites weighting less than 1MB each omitted.) > > > > Note: this patch only takes care of the sites omitted due to the scale threshold (b). It does not count how many sites had been omitted due to the baseline threshold (a). Since I still hope to remove that threshold completely with JDK-8261238, I did not put any work toward modifying the output here. > > ---- > > Tests: I manually ran runtime/NMT tests. Pretty simple, sure. Only minor nits. src/hotspot/share/services/memReporter.cpp line 307: > 305: // Don't report if site has reserved less than one unit of whatever our scale is > 306: if (scale() > 1 && amount_in_current_scale(virtual_memory_site->reserved()) == 0) { > 307: num_omitted ++; I think the Hotspot style is to say `num_omitted++`. src/hotspot/share/services/memReporter.hpp line 150: > 148: // Report virtual memory map > 149: void report_virtual_memory_map(); > 150: // Report malloc allocation sites; returns number of omitted sites. Here and two lines below, comments do not need trailing points. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2687 From shade at openjdk.java.net Fri Apr 16 08:03:44 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 16 Apr 2021 08:03:44 GMT Subject: RFR: 8261445: Use memory_order_relaxed for os::random(). In-Reply-To: References: Message-ID: <814OxqahJa2bPYZrN-SxEk5K7hSV81Ek0gdneJpQt0Q=.c4d07dd4-358f-4e3e-b61b-642cbdad7ea4@github.com> On Tue, 9 Feb 2021 14:49:12 GMT, Andrew Haley wrote: > os::random() is used a lot (once for every class) during HotSpot initialization, and it defaults to using a compare-and-swap operation with memory_order_conservative. We don't need that: it should be memory_order_relaxed. This one seems to have fallen through the cracks. @theRealAph, would you like to finish it? ------------- PR: https://git.openjdk.java.net/jdk/pull/2484 From david.holmes at oracle.com Fri Apr 16 09:08:18 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Apr 2021 19:08:18 +1000 Subject: RFR: 8265314: Obsolete the unused AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags In-Reply-To: <7at-d9Ddqslrgn3hQ2nLcfu9YZuuxghg5OyUOVqliBU=.1c6c4854-b710-458b-9419-47579fbc2c60@github.com> References: <7at-d9Ddqslrgn3hQ2nLcfu9YZuuxghg5OyUOVqliBU=.1c6c4854-b710-458b-9419-47579fbc2c60@github.com> Message-ID: <26bb64d6-acb2-6f23-928d-771a383f3509@oracle.com> On 16/04/2021 5:50 pm, Aleksey Shipilev wrote: > On Fri, 16 Apr 2021 01:35:12 GMT, David Holmes wrote: > >> The AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags became unused with the changes in JDK-8223312 and should have been obsoleted then. >> >> Thanks, >> David > > This looks fine. But I think this PR mistakenly references the CSR itself, rather than the implementation (JDK-8265313), which is why bots complain. Doh! Thanks Aleksey - yes I messed up. Will try to fix. David > ------------- > > Marked as reviewed by shade (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3527 > From sgehwolf at openjdk.java.net Fri Apr 16 09:46:36 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 16 Apr 2021 09:46:36 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <7NdGK5RgmmF8QHJ3ViVRKnSQVQK-AVmE_igqoj8d4gk=.18b4db5f-aaf6-4c7d-9d82-606fe5f3ad58@github.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> <7NdGK5RgmmF8QHJ3ViVRKnSQVQK-AVmE_igqoj8d4gk=.18b4db5f-aaf6-4c7d-9d82-606fe5f3ad58@github.com> Message-ID: <2lwQ07MWb51ujhzvAzuz32BliHBlQdltJRajaPd_iUQ=.23846a1e-e592-47fc-a2d6-4965bbca42be@github.com> On Fri, 16 Apr 2021 02:26:00 GMT, Yasumasa Suenaga wrote: > I agree with David, I think we should throw SkipException in this case. > > OTOH this test can catch incorrect behavior if HotSpot could not get CPU related values from cgroups even if `CONFIG_CFS_BANDWIDTH` is configured. Did you perhaps mean that post-patch the test would actually (wrongly) pass on a system with a broken implementation of CPU quota/period support in the container detection code? If so, I agree and, thus, don't like this suggested fix for that reason. > So I suggest to check `/boot/config-` in start of the test rather than throwing SkipException. If we cannot see `CONFIG_CFS_BANDWIDTH=y` in it, then we can throw SkipException. This suggestion depends on `/boot/config-$(uname -r)` being installed on the system under test. If it isn't, you're non the wiser and have to assume something. ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From sgehwolf at openjdk.java.net Fri Apr 16 09:55:45 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 16 Apr 2021 09:55:45 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> Message-ID: On Thu, 25 Mar 2021 20:11:30 GMT, Anton Ostrouhhov wrote: > Hello! > Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`. > > This is my first contribution so please tell me if i am wrong somewhere. Hi @aostrouhhov! > Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`. I think we need more information on how the actual system behaves in order to devise a sensible plan. Could you please provide the output of: $ java -Xlog:os+container=trace -version when run on the affected system? Is this a cgroups v1 or a cgroups v2 system? I'd also be interested in contents of files `/proc/cgroups`, `/proc/self/cgroup` and '/proc/self/mountinfo` on the affected system. ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From hseigel at openjdk.java.net Fri Apr 16 12:11:44 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 16 Apr 2021 12:11:44 GMT Subject: RFR: 8265313: Obsolete the unused AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 01:35:12 GMT, David Holmes wrote: > The AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags became unused with the changes in JDK-8223312 and should have been obsoleted then. > > Thanks, > David Looks good and trivial. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3527 From dholmes at openjdk.java.net Fri Apr 16 12:11:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Apr 2021 12:11:44 GMT Subject: RFR: 8265313: Obsolete the unused AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 01:35:12 GMT, David Holmes wrote: > The AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags became unused with the changes in JDK-8223312 and should have been obsoleted then. > > Thanks, > David Thanks Harold! I have to wait for the CSR to be approved before integrating anyway. ------------- PR: https://git.openjdk.java.net/jdk/pull/3527 From dholmes at openjdk.java.net Fri Apr 16 12:20:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Apr 2021 12:20:36 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> Message-ID: On Thu, 25 Mar 2021 20:11:30 GMT, Anton Ostrouhhov wrote: > Hello! > Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`. > > This is my first contribution so please tell me if i am wrong somewhere. I'm not sure my, simple, point is getting through. Here's the cgroupv1 code: /* cpu_quota * * Return the number of microseconds per period * process is guaranteed to run. * * return: * quota time in microseconds * -1 for no quota * OSCONTAINER_ERROR for not supported */ int CgroupV1Subsystem::cpu_quota() { GET_CONTAINER_INFO(int, _cpu->controller(), "/cpu.cfs_quota_us", "CPU Quota is: %d", "%d", quota); return quota; } But if GET_CONTAINER_INFO doesn't find /cpu.cfs_quota_us the macro does "return OSCONTAINER_ERROR" which is "return -2". Yet the spec states that if there is no quota then -1 is returned, so why are we not returning -1? ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From sgehwolf at openjdk.java.net Fri Apr 16 12:26:36 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 16 Apr 2021 12:26:36 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> Message-ID: On Fri, 16 Apr 2021 12:18:05 GMT, David Holmes wrote: > I'm not sure my, simple, point is getting through. Here's the cgroupv1 code: > > ``` > /* cpu_quota > * > * Return the number of microseconds per period > * process is guaranteed to run. > * > * return: > * quota time in microseconds > * -1 for no quota > * OSCONTAINER_ERROR for not supported > */ > int CgroupV1Subsystem::cpu_quota() { > GET_CONTAINER_INFO(int, _cpu->controller(), "/cpu.cfs_quota_us", > "CPU Quota is: %d", "%d", quota); > return quota; > } > ``` > > But if GET_CONTAINER_INFO doesn't find /cpu.cfs_quota_us the macro does "return OSCONTAINER_ERROR" which is "return -2". Yet the spec states that if there is no quota then -1 is returned, so why are we not returning -1? @dholmes-ora Because they're not equivalent. `-1` means, the system supports it in general, but no cgroups quota is in place. I.e. unlimited. For example A) `docker run --memory 200M ` on a cgroup capable system with all the kernel support should report the memory limit. B) `docker run `. Case B) would return -1. `-2` is usually something unexpected and means the system doesn't support it (be it by kernel config, the file not being present where a file is expected to be present, etc.). We want to distinguish those two cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From sgehwolf at openjdk.java.net Fri Apr 16 12:34:35 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 16 Apr 2021 12:34:35 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> Message-ID: On Thu, 25 Mar 2021 20:11:30 GMT, Anton Ostrouhhov wrote: > Hello! > Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`. > > This is my first contribution so please tell me if i am wrong somewhere. Reading through the code it looks like OSCONTAINER_ERROR is probably being reported in this case. Thus, `Whitebox.printOsInfo()` should print `not supported` for the CPU files in question. Perhaps the test could use this call and look for a match on the relevant metric for "not supported" and don't perform the match in that case. @aostrouhhov FYI. Alternatively, change the `GET_CONTAINER_INFO` macros to print trace messages for `OSCONTAINER_ERROR` cases and use that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From ysuenaga at openjdk.java.net Fri Apr 16 13:08:33 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 16 Apr 2021 13:08:33 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <2lwQ07MWb51ujhzvAzuz32BliHBlQdltJRajaPd_iUQ=.23846a1e-e592-47fc-a2d6-4965bbca42be@github.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> <7NdGK5RgmmF8QHJ3ViVRKnSQVQK-AVmE_igqoj8d4gk=.18b4db5f-aaf6-4c7d-9d82-606fe5f3ad58@github.com> <2lwQ07MWb51ujhzvAzuz32BliHBlQdltJRajaPd_iUQ=.23846a1e-e592-47fc-a2d6-4965bbca42be@github.com> Message-ID: On Fri, 16 Apr 2021 09:43:24 GMT, Severin Gehwolf wrote: > > I agree with David, I think we should throw SkipException in this case. > > OTOH this test can catch incorrect behavior if HotSpot could not get CPU related values from cgroups even if `CONFIG_CFS_BANDWIDTH` is configured. > > Did you perhaps mean that post-patch the test would actually (wrongly) pass on a system with a broken implementation of CPU quota/period support in the container detection code? If so, I agree and, thus, don't like this suggested fix for that reason. Yes, sorry for my English ????? > > So I suggest to check `/boot/config-` in start of the test rather than throwing SkipException. If we cannot see `CONFIG_CFS_BANDWIDTH=y` in it, then we can throw SkipException. > > This suggestion depends on `/boot/config-$(uname -r)` being installed on the system under test. If it isn't, you're non the wiser and have to assume something. I can see config file in Fedora, Alpine, and Ubuntu. In case of Fedora, it is provided by kernel-core package. so I guess most of Linux distros are providing it. If so, I think we can throw SkipException when the test cannot find it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From sgehwolf at openjdk.java.net Fri Apr 16 13:16:34 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 16 Apr 2021 13:16:34 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> <7NdGK5RgmmF8QHJ3ViVRKnSQVQK-AVmE_igqoj8d4gk=.18b4db5f-aaf6-4c7d-9d82-606fe5f3ad58@github.com> <2lwQ07MWb51ujhzvAzuz32BliHBlQdltJRajaPd_iUQ=.23846a1e-e592-47fc-a2d6-4965bbca42be@github.com> Message-ID: On Fri, 16 Apr 2021 13:05:28 GMT, Yasumasa Suenaga wrote: > I can see config file in Fedora, Alpine, and Ubuntu. In case of Fedora, it is provided by kernel-core package. so I guess most of Linux distros are providing it. If so, I think we can throw SkipException when the test cannot find it. Right. Note, however, `kernel-core` packages usually aren't installed in containers. So on a system like that (Raspberry Pi) and inside a container, the test would then be meaningless. ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From ysuenaga at openjdk.java.net Fri Apr 16 14:18:35 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 16 Apr 2021 14:18:35 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> <7NdGK5RgmmF8QHJ3ViVRKnSQVQK-AVmE_igqoj8d4gk=.18b4db5f-aaf6-4c7d-9d82-606fe5f3ad58@github.com> <2lwQ07MWb51ujhzvAzuz32BliHBlQdltJRajaPd_iUQ=.23846a1e-e592-47fc-a2d6-4965bbca42be@github.com> Message-ID: On Fri, 16 Apr 2021 13:13:31 GMT, Severin Gehwolf wrote: > > I can see config file in Fedora, Alpine, and Ubuntu. In case of Fedora, it is provided by kernel-core package. so I guess most of Linux distros are providing it. If so, I think we can throw SkipException when the test cannot find it. > > Right. Note, however, `kernel-core` packages usually aren't installed in containers. So on a system like that (Raspberry Pi) and inside a container, the test would then be meaningless. PlainTest.java does not require to run inside the container, it requires cgroups only. It does not use classes in `jdk.test.lib.containers.docker` like DockerBasicTest.java. The problem in PlainTest.java suffers only when `wb.isContainerized()` returns `true` - it does not indicates the process is inside container as we've discussed in #3280 . ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From sgehwolf at openjdk.java.net Fri Apr 16 14:55:37 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 16 Apr 2021 14:55:37 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> <7NdGK5RgmmF8QHJ3ViVRKnSQVQK-AVmE_igqoj8d4gk=.18b4db5f-aaf6-4c7d-9d82-606fe5f3ad58@github.com> <2lwQ07MWb51ujhzvAzuz32BliHBlQdltJRajaPd_iUQ=.23846a1e-e592-47fc-a2d6-4965bbca42be@github.com> Message-ID: <3008wmLk2Ry85o73J1bLPhqNMNE6E5mpssZDylr32Ys=.772f0965-dd24-47e6-b363-dfe83ef8861f@github.com> On Fri, 16 Apr 2021 14:16:06 GMT, Yasumasa Suenaga wrote: > > > I can see config file in Fedora, Alpine, and Ubuntu. In case of Fedora, it is provided by kernel-core package. so I guess most of Linux distros are providing it. If so, I think we can throw SkipException when the test cannot find it. > > > > > > Right. Note, however, `kernel-core` packages usually aren't installed in containers. So on a system like that (Raspberry Pi) and inside a container, the test would then be meaningless. > > PlainTest.java does not require to run inside the container, it requires cgroups only. It does not use classes in `jdk.test.lib.containers.docker` like DockerBasicTest.java. > The problem in PlainTest.java suffers only when `wb.isContainerized()` returns `true` - it does not indicates the process is inside container as we've discussed in #3280 . Understood. Nothing precludes it from being run in a docker container, though, does it? I've seen test setups which only run jtreg tests in containers. I'm not convinced we need to add a dependency on the `kernel-core` package in order to fix this test, that's all I'm saying :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From dcubed at openjdk.java.net Fri Apr 16 14:56:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Apr 2021 14:56:42 GMT Subject: RFR: 8265313: Obsolete the unused AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 01:35:12 GMT, David Holmes wrote: > The AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags became unused with the changes in JDK-8223312 and should have been obsoleted then. > > Thanks, > David Thumbs up! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3527 From stuefe at openjdk.java.net Fri Apr 16 17:02:38 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 16 Apr 2021 17:02:38 GMT Subject: RFR: JDK-8262165: NMT report should state how many callsites had been skipped In-Reply-To: <81Sy_MiX7NUCJdTWGK52nN-GCKIIt7tqXWAHY7i3sXY=.70c19c1c-a7be-408b-8d8f-23fb1930192b@github.com> References: <81Sy_MiX7NUCJdTWGK52nN-GCKIIt7tqXWAHY7i3sXY=.70c19c1c-a7be-408b-8d8f-23fb1930192b@github.com> Message-ID: On Fri, 16 Apr 2021 07:59:13 GMT, Aleksey Shipilev wrote: > Pretty simple, sure. Only minor nits. Great, thanks, Aleksey. Good to have this finally off the table. I'll add the suggested modifications before pushing. ------------- PR: https://git.openjdk.java.net/jdk/pull/2687 From sspitsyn at openjdk.java.net Fri Apr 16 19:17:56 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 16 Apr 2021 19:17:56 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 06:44:06 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed nits Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Fri Apr 16 19:35:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Apr 2021 19:35:04 GMT Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 Message-ID: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures: - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64 - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64 - JDK-8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64 - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64 - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64 ------------- Commit messages: - 8265370: ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64 - 8265368: ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64 - 8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64 - 8265363: ProblemList java/net/Socket/UdpSocket.java on macos-aarch64 - 8265361: ProblemList a few compiler/whitebox tests on macos-aarch64 - 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3549/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3549&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265358 Stats: 16 lines in 3 files changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3549/head:pull/3549 PR: https://git.openjdk.java.net/jdk/pull/3549 From bpb at openjdk.java.net Fri Apr 16 19:44:33 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 16 Apr 2021 19:44:33 GMT Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com> References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com> Message-ID: On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty wrote: > A set of trivial ProblemListing for macos-aarch64 Tier2 test failures: > > - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 > - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64 > - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64 > - JDK-8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64 > - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64 > - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64 Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3549 From mikael at openjdk.java.net Fri Apr 16 19:49:33 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 16 Apr 2021 19:49:33 GMT Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com> References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com> Message-ID: On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty wrote: > A set of trivial ProblemListing for macos-aarch64 Tier2 test failures: > > - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 > - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64 > - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64 > - JDK-8265366 ProblemList 2 javax/net/ssl/DTLS tests on macos-aarch64 > - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64 > - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64 Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3549 From dcubed at openjdk.java.net Fri Apr 16 20:16:06 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Apr 2021 20:16:06 GMT Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 [v2] In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com> References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com> Message-ID: > A set of trivial ProblemListing for macos-aarch64 Tier2 test failures: > > - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 > - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64 > - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64 > - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64 > - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64 Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Remove changes for JDK-8265366 at @fguallini's request. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3549/files - new: https://git.openjdk.java.net/jdk/pull/3549/files/5fb3de6a..7f245f4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3549&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3549&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3549/head:pull/3549 PR: https://git.openjdk.java.net/jdk/pull/3549 From mikael at openjdk.java.net Fri Apr 16 20:16:06 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 16 Apr 2021 20:16:06 GMT Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 [v2] In-Reply-To: References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com> Message-ID: On Fri, 16 Apr 2021 20:12:45 GMT, Daniel D. Daugherty wrote: >> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures: >> >> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 >> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64 >> - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64 >> - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64 >> - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64 > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Remove changes for JDK-8265366 at @fguallini's request. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3549 From dcubed at openjdk.java.net Fri Apr 16 20:16:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Apr 2021 20:16:07 GMT Subject: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 [v2] In-Reply-To: References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com> Message-ID: On Fri, 16 Apr 2021 19:42:06 GMT, Brian Burkhalter wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove changes for JDK-8265366 at @fguallini's request. > > Marked as reviewed by bpb (Reviewer). @bplb and @vidmik - Thanks for the reviews. I'm removing the changes for JDK-8265366 at @fguallini's request. ------------- PR: https://git.openjdk.java.net/jdk/pull/3549 From dcubed at openjdk.java.net Fri Apr 16 20:24:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Apr 2021 20:24:37 GMT Subject: Integrated: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 In-Reply-To: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com> References: <_-5JlNnDNuQFLLctYTMcmdAgWJOALgf4C9y-VyWiPVc=.86c6e1e3-14ae-474a-ab65-c0a0574ae96e@github.com> Message-ID: On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty wrote: > A set of trivial ProblemListing for macos-aarch64 Tier2 test failures: > > - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 > - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64 > - JDK-8265363 ProblemList java/net/Socket/UdpSocket.java on macos-aarch64 > - JDK-8265368 ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64 > - JDK-8265370 ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64 This pull request has now been integrated. Changeset: 888d80b5 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/888d80b5 Stats: 13 lines in 3 files changed: 13 ins; 0 del; 0 mod 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 8265361: ProblemList a few compiler/whitebox tests on macos-aarch64 8265363: ProblemList java/net/Socket/UdpSocket.java on macos-aarch64 8265368: ProblemList 3 java/net/httpclient/websocket tests on macos-aarch64 8265370: ProblemList java/net/MulticastSocket/Promiscuous.java on macos-aarch64 Reviewed-by: bpb, mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/3549 From bpb at openjdk.java.net Fri Apr 16 21:09:57 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 16 Apr 2021 21:09:57 GMT Subject: RFR: 8265381: ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp In-Reply-To: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com> References: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com> Message-ID: On Fri, 16 Apr 2021 21:01:33 GMT, Daniel D. Daugherty wrote: > A trivial change to ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3552 From dcubed at openjdk.java.net Fri Apr 16 21:09:57 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Apr 2021 21:09:57 GMT Subject: RFR: 8265381: ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp Message-ID: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com> A trivial change to ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp. ------------- Commit messages: - 8265381: ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp Changes: https://git.openjdk.java.net/jdk/pull/3552/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3552&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265381 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3552.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3552/head:pull/3552 PR: https://git.openjdk.java.net/jdk/pull/3552 From dcubed at openjdk.java.net Fri Apr 16 21:24:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Apr 2021 21:24:37 GMT Subject: Integrated: 8265381: ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp In-Reply-To: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com> References: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com> Message-ID: On Fri, 16 Apr 2021 21:01:33 GMT, Daniel D. Daugherty wrote: > A trivial change to ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp. This pull request has now been integrated. Changeset: 2c4075cb Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/2c4075cb Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8265381: ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/3552 From dcubed at openjdk.java.net Fri Apr 16 21:24:36 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Apr 2021 21:24:36 GMT Subject: RFR: 8265381: ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp In-Reply-To: References: <1d3fanUzNcRsQq4yVYnO4l1lVLLpwSz2RP3RUrEehhY=.febbe716-4ffb-420e-ada2-54ef613e6ac5@github.com> Message-ID: On Fri, 16 Apr 2021 21:05:41 GMT, Brian Burkhalter wrote: >> A trivial change to ProblemList runtime/logging/RedefineClasses.java on macos-x64 -Xcomp. > > Marked as reviewed by bpb (Reviewer). @bplb - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3552 From david.holmes at oracle.com Fri Apr 16 21:54:04 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 17 Apr 2021 07:54:04 +1000 Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> Message-ID: On 16/04/2021 10:26 pm, Severin Gehwolf wrote: > On Fri, 16 Apr 2021 12:18:05 GMT, David Holmes wrote: > >> I'm not sure my, simple, point is getting through. Here's the cgroupv1 code: >> >> ``` >> /* cpu_quota >> * >> * Return the number of microseconds per period >> * process is guaranteed to run. >> * >> * return: >> * quota time in microseconds >> * -1 for no quota >> * OSCONTAINER_ERROR for not supported >> */ >> int CgroupV1Subsystem::cpu_quota() { >> GET_CONTAINER_INFO(int, _cpu->controller(), "/cpu.cfs_quota_us", >> "CPU Quota is: %d", "%d", quota); >> return quota; >> } >> ``` >> >> But if GET_CONTAINER_INFO doesn't find /cpu.cfs_quota_us the macro does "return OSCONTAINER_ERROR" which is "return -2". Yet the spec states that if there is no quota then -1 is returned, so why are we not returning -1? > > @dholmes-ora Because they're not equivalent. `-1` means, the system supports it in general, but no cgroups quota is in place. I.e. unlimited. For example A) `docker run --memory 200M ` on a cgroup capable system with all the kernel support should report the memory limit. B) `docker run `. Case B) would return -1. `-2` is usually something unexpected and means the system doesn't support it (be it by kernel config, the file not being present where a file is expected to be present, etc.). We want to distinguish those two cases. I don't see why the user cares about this distinction. We might care for logging purposes but that is different. There is no difference to the end user between cgroups defines no quota and cgroups quotas are not compiled into the kernel. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3206 > From dcubed at openjdk.java.net Fri Apr 16 22:47:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Apr 2021 22:47:05 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 06:44:06 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed nits Reviewed the v09 incremental. Still thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From vlivanov at openjdk.java.net Fri Apr 16 23:09:40 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 16 Apr 2021 23:09:40 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 Message-ID: `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. Proposed fix is to start the search from the frame reported by `os::current_frame()`. Testing: - [x] failing test - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` ------------- Commit messages: - Merge branch 'master' into 8265218.mh_logging - Remove from test/hotspot/jtreg/ProblemList-Xcomp.txt - 8265218: trace_method_handle_stub fails to find calling frame on x86 Changes: https://git.openjdk.java.net/jdk/pull/3554/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3554&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265218 Stats: 7 lines in 2 files changed: 2 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3554.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3554/head:pull/3554 PR: https://git.openjdk.java.net/jdk/pull/3554 From stuefe at openjdk.java.net Sat Apr 17 04:57:16 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 17 Apr 2021 04:57:16 GMT Subject: RFR: JDK-8262165: NMT report should state how many callsites had been skipped [v2] In-Reply-To: References: Message-ID: > (This is a breakout from JDK-8261238, which seems to be stuck in review (https://github.com/openjdk/jdk/pull/2428). I factor out the display changes, which hopefully are non-controversial enough to get upstream easily.) > > NMT silently omits call sites in its report whose allocation rate is too small to get over certain, hidden, thresholds: > a) there is a hard wired threshold of 1K in the baseline collector > b) we also skip all sites whose size is less than what the unit is (eg scale=G, we skip all allocations < 1G > > NMT report should state how many call sites had been omitted. > > ---- > > The patch adds a counter in the NMT reporter to count omitted call sites, then prints that counter out. > > In base report, just a generic message is shown to notify the user that categories > scale are ignored: > > > thomas at mainframe$ jcmd Interl VM.native_memory scale=m > 2847: > > Native Memory Tracking: > > (Omitting categories weighting less than 1MB) > > Total: reserved=5540MB, committed=147MB > - Java Heap (reserved=3996MB, committed=34MB) > (mmap: reserved=3996MB, committed=34MB) > > > > In detail report, the total count of omitted call sites is displayed at the bottom: > > > thomas at mainframe$ jcmd Interl VM.native_memory scale=m detail > 2847: > > > > [0x00007f4e062e3e6b] os::reserve_memory(unsigned long, bool, MEMFLAGS)+0x16b > [0x00007f4e05ac4f47] MmapArrayAllocator::allocate(unsigned long, MEMFLAGS)+0x127 > [0x00007f4e05ac4cb2] G1FromCardCache::initialize(unsigned int)+0xe2 > [0x00007f4e05a863f1] G1CollectedHeap::initialize()+0x3c1 > (reserved=1MB, committed=1MB Type=GC) > > (183 call sites weighting less than 1MB each omitted.) > > > > Note: this patch only takes care of the sites omitted due to the scale threshold (b). It does not count how many sites had been omitted due to the baseline threshold (a). Since I still hope to remove that threshold completely with JDK-8261238, I did not put any work toward modifying the output here. > > ---- > > Tests: I manually ran runtime/NMT tests. Thomas Stuefe 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 - feedback aleksey - JDK-8262165 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2687/files - new: https://git.openjdk.java.net/jdk/pull/2687/files/a6bbf78a..31ff1eb9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2687&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2687&range=00-01 Stats: 183730 lines in 5840 files changed: 108394 ins; 53031 del; 22305 mod Patch: https://git.openjdk.java.net/jdk/pull/2687.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2687/head:pull/2687 PR: https://git.openjdk.java.net/jdk/pull/2687 From dholmes at openjdk.java.net Sat Apr 17 05:40:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 17 Apr 2021 05:40:36 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 In-Reply-To: References: Message-ID: <2_xzvM3b_0D2QgN9Ne6bMoHW2CigySF8_JE-L_Au0Ok=.b699d607-2431-419c-b427-4fac2699b1b4@github.com> On Fri, 16 Apr 2021 22:50:39 GMT, Vladimir Ivanov wrote: > `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. > > The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. > > Proposed fix is to start the search from the frame reported by `os::current_frame()`. > > Testing: > - [x] failing test > - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` Hi Vladimir, Based on the problem description the solution seems correct, but as mentioned offline I'm always concerned that the correct use of "current frame" can depend on the presence or absence of inlining. So it is never clear to me that changes like this do not simply switch the set of contexts where this code is correct, based on the problem being solved today. Thanks, David src/hotspot/cpu/x86/methodHandles_x86.cpp line 558: > 556: FrameValues values; > 557: > 558: frame cur_frame = os::current_frame(); // reports caller's frame! It is unclear what "caller" is relative to in that comment - is it the caller of os::current_frame() as seen by os::current_frame(), or is it the caller of the current method that is invoking os::current_frame() ? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3554 From shade at openjdk.java.net Sat Apr 17 06:24:41 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sat, 17 Apr 2021 06:24:41 GMT Subject: Integrated: JDK-8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 16:56:31 GMT, Aleksey Shipilev wrote: > I stumbled upon this when doing some Shenandoah work. The development code tried to lock the `leaf` lock, while already holding the `access` lock. Normally it would have been detected by VM, but instead, we tried to recursively acquire `tty_lock` for `Thread::print_owned_locks`. But that `tty` lock is still ranked higher than `access`, so deadlock detection triggers over and over again until we run out of stack and crash hard. `tty` and `access` are ranked this way because of [JDK-8214315](https://bugs.openjdk.java.net/browse/JDK-8214315). Read the rest in the bug. > > I believe the way out is to only enter `Thread::print_owned_locks` when we know deadlock detection code would not run in circles. New test for `access` and `leaf` shows the original failure. Another new test checks `tty` and `special` to verify that the check should be `> tty`, not `>= tty`. > > Additional testing: > - [x] Linux x86_64 fastdebug tier1 > - [x] New regression tests (fail without the patch, pass wit it) This pull request has now been integrated. Changeset: 66f89870 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/66f89870 Stats: 68 lines in 2 files changed: 67 ins; 0 del; 1 mod 8265298: Hard VM crash when deadlock between "access" and higher ranked lock is detected Reviewed-by: pchilanomate, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3524 From whuang at openjdk.java.net Sat Apr 17 07:42:36 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Sat, 17 Apr 2021 07:42:36 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Thu, 8 Apr 2021 05:02:27 GMT, David Holmes wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> add throw exception > > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 58: > >> 56: public void test() throws Throwable { >> 57: >> 58: CountDownLatch latch = new CountDownLatch(1); > > The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives. @dholmes-ora ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From david.holmes at oracle.com Sat Apr 17 12:45:34 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 17 Apr 2021 22:45:34 +1000 Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: <55d02ed5-4170-5056-98f1-2910c2fb2fe8@oracle.com> On 17/04/2021 5:42 pm, Wang Huang wrote: > On Thu, 8 Apr 2021 05:02:27 GMT, David Holmes wrote: > >>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >>> >>> add throw exception >> >> test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 58: >> >>> 56: public void test() throws Throwable { >>> 57: >>> 58: CountDownLatch latch = new CountDownLatch(1); >> >> The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives. > > @dholmes-ora Not sure what commentary you are looking for. CyclicBarrier should work better for ensuring concurrent attempts in theory. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3392 > From david.holmes at oracle.com Sat Apr 17 12:46:53 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 17 Apr 2021 22:46:53 +1000 Subject: RFR: 8265313: Obsolete the unused AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags In-Reply-To: References: Message-ID: <58adb3c6-d7ae-96e9-abf9-f23754135bfc@oracle.com> On 17/04/2021 12:56 am, Daniel D.Daugherty wrote: > On Fri, 16 Apr 2021 01:35:12 GMT, David Holmes wrote: > >> The AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags became unused with the changes in JDK-8223312 and should have been obsoleted then. >> >> Thanks, >> David > > Thumbs up! Thanks for the review here and of the CSR request Dan! David > ------------- > > Marked as reviewed by dcubed (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3527 > From dholmes at openjdk.java.net Sun Apr 18 04:29:47 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 18 Apr 2021 04:29:47 GMT Subject: Integrated: 8265313: Obsolete the unused AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 01:35:12 GMT, David Holmes wrote: > The AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags became unused with the changes in JDK-8223312 and should have been obsoleted then. > > Thanks, > David This pull request has now been integrated. Changeset: 73d5f3b5 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/73d5f3b5 Stats: 8 lines in 2 files changed: 2 ins; 6 del; 0 mod 8265313: Obsolete the unused AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags Reviewed-by: shade, hseigel, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3527 From yyang at openjdk.java.net Mon Apr 19 02:44:09 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 19 Apr 2021 02:44:09 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp [v3] In-Reply-To: References: Message-ID: > Remove unnecessary inclusion of bytecodeHistogram.hpp Yi Yang has updated the pull request incrementally with one additional commit since the last revision: add include in macroAssembler_.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3530/files - new: https://git.openjdk.java.net/jdk/pull/3530/files/a9f01b76..b9a9bb6e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3530&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3530&range=01-02 Stats: 4 lines in 4 files changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3530/head:pull/3530 PR: https://git.openjdk.java.net/jdk/pull/3530 From yyang at openjdk.java.net Mon Apr 19 02:46:33 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 19 Apr 2021 02:46:33 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 06:27:07 GMT, Yi Yang wrote: > > > Looks like these files refer to `(BytecodeCounter)|(BytecodeHistogram)(BytecodePairHistogram)` but are missing the inclusion of bytecodeHistogram.hpp > > > > > > * cpu/aarch64/macroAssembler_aarch64.cpp > > > * cpu/arm/macroAssembler_arm.cpp > > > * cpu/x86/macroAssembler_x86.cpp > > > > > > See https://github.com/iklam/tools/blob/main/headers/find_include_problems.sh > > > The problems can usually be found by building without precompiled headers. > > > > > > Yes, the inclusion of bytecodeHistogram.hpp in sharedRuntime.hpp should remain, others are really unnecessary.(Build without precompile header) > > sharedRuntime.hpp does not need to include bytecodeHistogram.hpp, since it doesn't use any of the 3 classes declared in bytecodeHistogram.hpp. You should add bytecodeHistogram.hpp to the 3 files I listed above instead. Hi Ioi, I've added `#include "interpreter/bytecodeHistogram.hpp"` in macroAssembler_.cpp you listed above. Build passed w and w/o precompile header in x64. ------------- PR: https://git.openjdk.java.net/jdk/pull/3530 From whuang at openjdk.java.net Mon Apr 19 04:38:35 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 19 Apr 2021 04:38:35 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Sat, 17 Apr 2021 07:40:05 GMT, Wang Huang wrote: >> test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 58: >> >>> 56: public void test() throws Throwable { >>> 57: >>> 58: CountDownLatch latch = new CountDownLatch(1); >> >> The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives. > > @dholmes-ora > The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives. I have tested a small case the `CyclicBarrier ` version and `CountDownLatch ` version on `JDK17` & `JDK11`. It seems that : * For `JDK17`, the wake-up time between two threads in the `CyclicBarrier ` version is bigger than the `CountDownLatch ` version. In other words, the `CountDownLatch ` version can trigger this bug more easily . * the `CyclicBarrier ` version and the `CountDownLatch ` version running under `JDK11` have the same performance. // CountDownLatch version public class TestCountDownLatch { public static void main(String args[]) { CountDownLatch latch1 = new CountDownLatch(1); CountDownLatch latch2 = new CountDownLatch(2); MyThread t1 = new MyThread(latch1, latch2); MyThread t2 = new MyThread(latch1, latch2); t1.start(); t2.start(); try { // waiting thread creation latch2.await(); latch1.countDown(); t1.join(); t2.join(); } catch (InterruptedException e) {} System.out.println(Math.abs(t1.getAwakeTime() - t2.getAwakeTime())); } static class MyThread extends Thread { private CountDownLatch latch1; private CountDownLatch latch2; private long awaketime; MyThread(CountDownLatch latch1, CountDownLatch latch2) { this.latch1 = latch1; this.latch2 = latch2; } @Override public void run() { try { latch2.countDown(); // Try to have all threads trigger the nesthost check at the same time latch1.await(); awaketime = System.nanoTime(); } catch (InterruptedException e) {} } public long getAwakeTime() { return awaketime; } } } // CyclicBarrier version import java.util.concurrent.CountDownLatch; import java.util.concurrent.CyclicBarrier; public class TestCyclicBarrier { public static void main(String args[]) { CyclicBarrier barrier = new CyclicBarrier(2); MyThread t1 = new MyThread(barrier); MyThread t2 = new MyThread(barrier); t1.start(); t2.start(); try { t1.join(); t2.join(); } catch (InterruptedException e) {} System.out.println(Math.abs(t1.getAwakeTime() - t2.getAwakeTime())); } static class MyThread extends Thread { private CyclicBarrier barrier; private long awaketime; MyThread(CyclicBarrier barrier) { this.barrier = barrier; } @Override public void run() { try { // Try to have all threads trigger the nesthost check at the same time barrier.await(); awaketime = System.nanoTime(); } catch (Exception e) {} } public long getAwakeTime() { return awaketime; } } } * results: - `CountDownLatch` against `CyclicBarrier` ``` CountDownLatch: 3960 CyclicBarrier: 3361280 CountDownLatch: 6120 CyclicBarrier: 3337540 CountDownLatch: 6160 CyclicBarrier: 3462920 CountDownLatch: 9150 CyclicBarrier: 3328090 CountDownLatch: 6580 CyclicBarrier: 3345450 CountDownLatch: 6340 CyclicBarrier: 3342900 CountDownLatch: 1330 CyclicBarrier: 3379210 CountDownLatch: 7780 CyclicBarrier: 3219020 CountDownLatch: 2460 CyclicBarrier: 3297020 CountDownLatch: 7320 CyclicBarrier: 3332770 - `JDK17` against `CyclicBarrier` CyclicBarrier jdk17: 3188590 CyclicBarrier jdk11: 49090 CyclicBarrier jdk17: 3123340 CyclicBarrier jdk11: 14680 CyclicBarrier jdk17: 3107910 CyclicBarrier jdk11: 780 CyclicBarrier jdk17: 3072600 CyclicBarrier jdk11: 1720 CyclicBarrier jdk17: 3164340 CyclicBarrier jdk11: 41020 CyclicBarrier jdk17: 3098490 CyclicBarrier jdk11: 7060 CyclicBarrier jdk17: 3058220 CyclicBarrier jdk11: 14750 CyclicBarrier jdk17: 3052460 CyclicBarrier jdk11: 660 CyclicBarrier jdk17: 3083650 CyclicBarrier jdk11: 14670 CyclicBarrier jdk17: 3116260 CyclicBarrier jdk11: 850 ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From stuefe at openjdk.java.net Mon Apr 19 05:16:43 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 19 Apr 2021 05:16:43 GMT Subject: RFR: JDK-8261238: NMT should not limit baselining by size threshold [v5] In-Reply-To: <-lC9Ton50BkMMCrq3L21QVM6ywOgRrQl5sHXDKMzWpI=.99ec02eb-8695-4422-8152-0b1473a14e8c@github.com> References: <-lC9Ton50BkMMCrq3L21QVM6ywOgRrQl5sHXDKMzWpI=.99ec02eb-8695-4422-8152-0b1473a14e8c@github.com> Message-ID: On Tue, 23 Feb 2021 07:14:04 GMT, Thomas Stuefe wrote: >> NMT is a very useful tool to detect memory leaks. Its easy to use, relatively cheap and requires almost zero setup. >> >> But it artificially limits output to call sites with >1K total memory consumption. That is not helpful, as it confuses the developer and obscures possible memory leaks. It also introduces subtle display errors in that callsites suddenly seem to appear, when comparing to the baseline, with a load of >1K when in fact they had been there already when the baseline was taken. >> >> I propose to remove the 1K limit completely. This will marginally increase the costs of taking "detail" NMT reports by about 210K for a single report, 420K for a report done using a baseline. >> >> If this is really a problem preventing us from getting more precise NMT output (really?) there are possibilities to decrease the cost again by sharing call stacks by reference instead of copying them around. I have a patch in work which does just that (https://bugs.openjdk.java.net/browse/JDK-8261491), but I honestly think adding 200-400K *temporarily* during NMT detail reporting would not be such a big deal. > > Thomas Stuefe 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 > - Split out display changes > - Exclude zero-sized regions from baseline > - Start Gentle Ping. Could I please have reviews? ------------- PR: https://git.openjdk.java.net/jdk/pull/2428 From iklam at openjdk.java.net Mon Apr 19 06:06:34 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 19 Apr 2021 06:06:34 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 02:44:09 GMT, Yi Yang wrote: >> Remove unnecessary inclusion of bytecodeHistogram.hpp > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > add include in macroAssembler_.cpp LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3530 From dholmes at openjdk.java.net Mon Apr 19 06:19:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 19 Apr 2021 06:19:00 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 06:44:06 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed nits Hi Robbin, I have gone through everything again in detail. A few comments on comments and a couple of details I'm still not really clear on. A couple of small renaming requests, but otherwise this is good to go - with the caveat of a future RFE to clear up the suspend-while-locking implementations so things are more cleanly encapsulated. Thanks, David src/hotspot/share/runtime/handshake.cpp line 630: > 628: // This is the closure that prevents a suspended JavaThread from > 629: // escaping the suspend request. > 630: class ThreadSuspensionHandshake : public AsyncHandshakeClosure { I still find ThreadSuspensionHandShake versus SuspendThreadHandshake to be too similarly named and with no obvious way to remember which one is which. Perhaps this one could be called ThreadSelfSuspensionHandshake instead? src/hotspot/share/runtime/handshake.cpp line 636: > 634: JavaThread* target = thr->as_Java_thread(); > 635: target->handshake_state()->do_self_suspend(); > 636: } As this must be the current thread we are dealing with can we rename the variables to indicate that. src/hotspot/share/runtime/handshake.hpp line 128: > 126: // must take slow path, process_by_self(), if _lock is held. > 127: bool should_process() { > 128: // When doing thread suspension the holder of the _lock Potentially this could be any async handshake operation - right? It seems odd to talk specifically about thread suspension in the core of the handshake code. src/hotspot/share/runtime/handshake.hpp line 131: > 129: // can add an asynchronous handshake to queue. > 130: // To make sure it is seen by the handshakee, the handshakee must first > 131: // check the _lock, if held go to slow path. ..., _and_ if held ... src/hotspot/share/runtime/handshake.hpp line 133: > 131: // check the _lock, if held go to slow path. > 132: // Since the handshakee is unsafe if _lock gets locked after this check > 133: // we know another thread cannot process any handshakes. I can't quite understand this comment. I'm not sure what thread is calling this method and when, in relation to what the handshakee may be doing. src/hotspot/share/runtime/handshake.hpp line 134: > 132: // Since the handshakee is unsafe if _lock gets locked after this check > 133: // we know another thread cannot process any handshakes. > 134: // Now we can check queue if there is anything we should process. // Now we can check the queue to see if there is anything we should process. src/hotspot/share/runtime/handshake.hpp line 157: > 155: Thread* active_handshaker() const { return _active_handshaker; } > 156: > 157: // Suspend/resume support Taking a step back I can't help but think that this is entirely the wrong place to have the suspend/resume API and supporting code. It is only here because we re-use the HandshakeState _lock monitor right? If we introduced a new thread-suspension monitor instead then this code would all reside somewhere else - probably in the JavaThread class. src/hotspot/share/runtime/mutex.hpp line 70: > 68: tty = access + 2, > 69: special = tty + 3, > 70: oopstorage = special + 3, Why +3? I'm assuming to keep the same numeric value as before, but that doesn't seem necessary and just seems to add to the mystery of why these ranks are defined in such a strange way. src/hotspot/share/runtime/thread.cpp line 1444: > 1442: } > 1443: > 1444: // The careful dance between thread suspension and exit is handled here. :) It isn't really a "careful dance" any more, as it is very straight forward. exit() can't race with a suspend request as such because we won't hit a handshake polling point. src/hotspot/share/runtime/thread.cpp line 1793: > 1791: bool JavaThread::java_suspend() { > 1792: ThreadsListHandle tlh; > 1793: if (!tlh.includes(this)) { Pre-existing: this check bothers me. Surely we should just be asserting "this" thread is in a TL as we are supposed to have ensured that before we even got this far. Future RFE. src/hotspot/share/runtime/thread.cpp line 1814: > 1812: // state before returning are performed. The current thread is required to > 1813: // change to _thread_blocked in order to be seen to be safepoint/handshake safe > 1814: // whilst suspended and only after becoming handshake safe, the other thread can It is still not at all clear to me what suspended has to do with the execution of this method. The new code just ignores thread suspension. It seems to me that the old code could also have ignored suspension if the checks in handle_special_runtime_exit_condition had be reordered. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java line 83: > 81: } > 82: > 83: public boolean isExtSuspended() { A new comment to avoid the "resolved" conversation. I'm still not sure you can just delete this API from the SA. @sspitsyn do you know what the obligations are with respect to the S.A here? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From dholmes at openjdk.java.net Mon Apr 19 06:28:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 19 Apr 2021 06:28:39 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 02:44:09 GMT, Yi Yang wrote: >> Remove unnecessary inclusion of bytecodeHistogram.hpp > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > add include in macroAssembler_.cpp Still LGTM. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3530 From yyang at openjdk.java.net Mon Apr 19 06:44:34 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 19 Apr 2021 06:44:34 GMT Subject: RFR: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 02:44:09 GMT, Yi Yang wrote: >> Remove unnecessary inclusion of bytecodeHistogram.hpp > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > add include in macroAssembler_.cpp Thanks Ioi and David for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/3530 From david.holmes at oracle.com Mon Apr 19 06:47:37 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 19 Apr 2021 16:47:37 +1000 Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: <2fbff2f3-5039-bff8-95d6-6ee43a8814ac@oracle.com> On 19/04/2021 2:38 pm, Wang Huang wrote: > On Sat, 17 Apr 2021 07:40:05 GMT, Wang Huang wrote: > >>> test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 58: >>> >>>> 56: public void test() throws Throwable { >>>> 57: >>>> 58: CountDownLatch latch = new CountDownLatch(1); >>> >>> The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives. >> >> @dholmes-ora > >> The use of CDL doesn't guarantee that both threads have reached the await() before the main thread does the countDown(). If you use a CyclicBarrier instead it will trip when the second thread arrives. > > I have tested a small case the `CyclicBarrier ` version and `CountDownLatch ` version on `JDK17` & `JDK11`. It seems that : > * For `JDK17`, the wake-up time between two threads in the `CyclicBarrier ` version is bigger than the `CountDownLatch ` version. In other words, the `CountDownLatch ` version can trigger this bug more easily . So ... thinking about what can happen here Case 1: countdown latch The thread that does the countdown() could do that before either thread calls await(), between the two calls to await(), or after both calls to await(). So how close in time the two threads are to getting the nesthost will depend on scheduling and whether either thread actually blocked in await(). So I can see how we can just be lucky here and both threads sail through the latch at around the same time without needing to block. Case 2: cyclic barrier The first thread to arrive has to block - no choice. The last thread to arrive never blocks. So we are actually guaranteed to see worse behaviour here as the last thread sails through the barrier and does the nesthost lookup well ahead of the thread that had to block. So while logically the cyclic barrier releases all threads "at the time time", in terms of implementation we've added a lot of overhead to the blocked threads. Conversely the CDL is not guaranteed to show better bug reproducability (extreme case - run on a uniprocessor) but in practice as long as we have a few CPUs to play with it likely will behave "better". Okay - the CDL version is what we should go with. Sorry to have taken up so much time on this. I didn't expect you to benchmark things. :) Thanks, David > * the `CyclicBarrier ` version and the `CountDownLatch ` version running under `JDK11` have the same performance. > > // CountDownLatch version > public class TestCountDownLatch { > > public static void main(String args[]) { > CountDownLatch latch1 = new CountDownLatch(1); > CountDownLatch latch2 = new CountDownLatch(2); > > MyThread t1 = new MyThread(latch1, latch2); > MyThread t2 = new MyThread(latch1, latch2); > > t1.start(); > t2.start(); > > try { > // waiting thread creation > latch2.await(); > latch1.countDown(); > > t1.join(); > t2.join(); > } catch (InterruptedException e) {} > > System.out.println(Math.abs(t1.getAwakeTime() - t2.getAwakeTime())); > } > > static class MyThread extends Thread { > private CountDownLatch latch1; > private CountDownLatch latch2; > private long awaketime; > > MyThread(CountDownLatch latch1, CountDownLatch latch2) { > this.latch1 = latch1; > this.latch2 = latch2; > } > > @Override > public void run() { > try { > latch2.countDown(); > // Try to have all threads trigger the nesthost check at the same time > latch1.await(); > awaketime = System.nanoTime(); > } catch (InterruptedException e) {} > } > > public long getAwakeTime() { > return awaketime; > } > } > } > > > > // CyclicBarrier version > import java.util.concurrent.CountDownLatch; > import java.util.concurrent.CyclicBarrier; > > public class TestCyclicBarrier { > > public static void main(String args[]) { > CyclicBarrier barrier = new CyclicBarrier(2); > > MyThread t1 = new MyThread(barrier); > MyThread t2 = new MyThread(barrier); > > t1.start(); > t2.start(); > > try { > t1.join(); > t2.join(); > } catch (InterruptedException e) {} > > System.out.println(Math.abs(t1.getAwakeTime() - t2.getAwakeTime())); > } > > static class MyThread extends Thread { > private CyclicBarrier barrier; > private long awaketime; > > MyThread(CyclicBarrier barrier) { > this.barrier = barrier; > } > > @Override > public void run() { > try { > // Try to have all threads trigger the nesthost check at the same time > barrier.await(); > awaketime = System.nanoTime(); > } catch (Exception e) {} > } > > public long getAwakeTime() { > return awaketime; > } > } > } > > * results: > - `CountDownLatch` against `CyclicBarrier` > ``` > CountDownLatch: 3960 > CyclicBarrier: 3361280 > CountDownLatch: 6120 > CyclicBarrier: 3337540 > CountDownLatch: 6160 > CyclicBarrier: 3462920 > CountDownLatch: 9150 > CyclicBarrier: 3328090 > CountDownLatch: 6580 > CyclicBarrier: 3345450 > CountDownLatch: 6340 > CyclicBarrier: 3342900 > CountDownLatch: 1330 > CyclicBarrier: 3379210 > CountDownLatch: 7780 > CyclicBarrier: 3219020 > CountDownLatch: 2460 > CyclicBarrier: 3297020 > CountDownLatch: 7320 > CyclicBarrier: 3332770 > > - `JDK17` against `CyclicBarrier` > > CyclicBarrier jdk17: 3188590 > CyclicBarrier jdk11: 49090 > CyclicBarrier jdk17: 3123340 > CyclicBarrier jdk11: 14680 > CyclicBarrier jdk17: 3107910 > CyclicBarrier jdk11: 780 > CyclicBarrier jdk17: 3072600 > CyclicBarrier jdk11: 1720 > CyclicBarrier jdk17: 3164340 > CyclicBarrier jdk11: 41020 > CyclicBarrier jdk17: 3098490 > CyclicBarrier jdk11: 7060 > CyclicBarrier jdk17: 3058220 > CyclicBarrier jdk11: 14750 > CyclicBarrier jdk17: 3052460 > CyclicBarrier jdk11: 660 > CyclicBarrier jdk17: 3083650 > CyclicBarrier jdk11: 14670 > CyclicBarrier jdk17: 3116260 > CyclicBarrier jdk11: 850 > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3392 > From rehn at openjdk.java.net Mon Apr 19 07:18:48 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 19 Apr 2021 07:18:48 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 04:19:28 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed nits > > src/hotspot/share/runtime/handshake.cpp line 630: > >> 628: // This is the closure that prevents a suspended JavaThread from >> 629: // escaping the suspend request. >> 630: class ThreadSuspensionHandshake : public AsyncHandshakeClosure { > > I still find ThreadSuspensionHandShake versus SuspendThreadHandshake to be too similarly named and with no obvious way to remember which one is which. Perhaps this one could be called ThreadSelfSuspensionHandshake instead? Fixed > src/hotspot/share/runtime/handshake.cpp line 636: > >> 634: JavaThread* target = thr->as_Java_thread(); >> 635: target->handshake_state()->do_self_suspend(); >> 636: } > > As this must be the current thread we are dealing with can we rename the variables to indicate that. Fixed > src/hotspot/share/runtime/handshake.hpp line 128: > >> 126: // must take slow path, process_by_self(), if _lock is held. >> 127: bool should_process() { >> 128: // When doing thread suspension the holder of the _lock > > Potentially this could be any async handshake operation - right? It seems odd to talk specifically about thread suspension in the core of the handshake code. Changed > src/hotspot/share/runtime/handshake.hpp line 131: > >> 129: // can add an asynchronous handshake to queue. >> 130: // To make sure it is seen by the handshakee, the handshakee must first >> 131: // check the _lock, if held go to slow path. > > ..., _and_ if held ... Fixed > src/hotspot/share/runtime/handshake.hpp line 133: > >> 131: // check the _lock, if held go to slow path. >> 132: // Since the handshakee is unsafe if _lock gets locked after this check >> 133: // we know another thread cannot process any handshakes. > > I can't quite understand this comment. I'm not sure what thread is calling this method and when, in relation to what the handshakee may be doing. The handshakee is in a safe state, e.g. blocked and does: Point A: set_thread_state_fence(_thread_blocked_trans); ... Point B: _lock.is_locked() While the processor thread does: Point X: _lock.try_lock(); ... Point Z: thread->thread_state(); If point B is passed with a non-locked lock, point Z is guaranteed to see an unsafe thread and will not start to process ay handshakes. Is that make sense, maybe the comment make more sense ? :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 19 07:21:57 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 19 Apr 2021 07:21:57 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 04:34:00 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed nits > > src/hotspot/share/runtime/handshake.hpp line 134: > >> 132: // Since the handshakee is unsafe if _lock gets locked after this check >> 133: // we know another thread cannot process any handshakes. >> 134: // Now we can check queue if there is anything we should process. > > // Now we can check the queue to see if there is anything we should process. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 19 07:29:59 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 19 Apr 2021 07:29:59 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 04:43:15 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed nits > > src/hotspot/share/runtime/handshake.hpp line 157: > >> 155: Thread* active_handshaker() const { return _active_handshaker; } >> 156: >> 157: // Suspend/resume support > > Taking a step back I can't help but think that this is entirely the wrong place to have the suspend/resume API and supporting code. It is only here because we re-use the HandshakeState _lock monitor right? If we introduced a new thread-suspension monitor instead then this code would all reside somewhere else - probably in the JavaThread class. When going to blocked inside the async handshake we **must** unlock the HandshakeState lock. Thus _lock.wait() unlocks and gives us something to notify. We could do: _lock.unlock(); { MutexLocker(SomeOtherLock) ml; SomeOtherLock.wait(); } _lock.lock(); Another alternative is to create a friend class which uses the HandshakeState lock and having the API there instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rrich at openjdk.java.net Mon Apr 19 07:30:00 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 19 Apr 2021 07:30:00 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: <_7hckHiny6Ljshr5-Bo1rJ4Z7nb5BHj1y364ODjnbdw=.dbd5eac3-3f5f-4d96-a46f-cd984a22c4eb@github.com> On Mon, 19 Apr 2021 05:48:44 GMT, David Holmes wrote: > It is still not at all clear to me what suspended has to do with the execution > of this method. The new code just ignores thread suspension. The caller enters a safe state. It can be suspended iff safe, so the old code checked for suspension. With the new code suspension is part of handshake processing, so it is sufficient to check for pending handshakes. > It seems to me that the old code could also have ignored suspension if the > checks in handle_special_runtime_exit_condition had be reordered. In that case JavaThread::java_suspend_self_with_safepoint_check() would have to be changed to check for `Thread::is_obj_deopt_suspend()` and handle it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 19 07:32:59 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 19 Apr 2021 07:32:59 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 04:47:33 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed nits > > src/hotspot/share/runtime/mutex.hpp line 70: > >> 68: tty = access + 2, >> 69: special = tty + 3, >> 70: oopstorage = special + 3, > > Why +3? I'm assuming to keep the same numeric value as before, but that doesn't seem necessary and just seems to add to the mystery of why these ranks are defined in such a strange way. Yes I wanted to keep the numeric rank. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 19 07:38:10 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 19 Apr 2021 07:38:10 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 06:07:54 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed nits > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java line 83: > >> 81: } >> 82: >> 83: public boolean isExtSuspended() { > > A new comment to avoid the "resolved" conversation. I'm still not sure you can just delete this API from the SA. @sspitsyn do you know what the obligations are with respect to the S.A here? The SA do not have the HandshakeState class implemented, so there is a lot a work to make this flag work. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Mon Apr 19 08:08:33 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 19 Apr 2021 08:08:33 GMT Subject: RFR: 8257831: Suspend with handshakes [v11] In-Reply-To: References: Message-ID: > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Fixed DavidH second review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3191/files - new: https://git.openjdk.java.net/jdk/pull/3191/files/d6e091da..5a4d52ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=09-10 Stats: 13 lines in 2 files changed: 1 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191 PR: https://git.openjdk.java.net/jdk/pull/3191 From thomas.stuefe at gmail.com Mon Apr 19 08:10:33 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 19 Apr 2021 10:10:33 +0200 Subject: Backport of JDK-8249672 ("Include microcode revision in features_string") to JDK-11.0.10 breaks compiling it on Oracle Solaris 11.4 In-Reply-To: <473d105d-9cd3-475f-726a-97fe93c2bb4c@steffen-moser.de> References: <473d105d-9cd3-475f-726a-97fe93c2bb4c@steffen-moser.de> Message-ID: Hi Steffen, (compiler-dev -> runtime-dev) Thanks for reporting this. I opened https://bugs.openjdk.java.net/browse/JDK-8265417 to track this issue. I guess not many people build Solaris x86. We should at least stub out the method for Solaris x86 to get the build going. I am not sure it is worth the cycles to actually implement this, since Solaris is obsolete and Solaris x86 is such a niche platform. But we should keep the build intact. The backport was done by Oracle. I am not sure if Solaris x86 is a supported platform, and if it is regularly tested. Does not seem that way. Cheers Thomas On Sun, Apr 18, 2021 at 1:54 PM Steffen Moser wrote: > Hi all, > > I am new into JDK contribution/bug reporting, so I really hope I've > chosen the right way to report a bug - at least I could neither find a > possibility to register for openjdk.java.net nor did my Oracle SSO > account work on this site. > > Bug report: In JDK-8249672, the microcode version of an x86 CPU was > added to the "features_string" printed in an hs_err_pidXXXXX log file. > As far as I know, it was introduced to JDK-16 and back-ported to both, > JDK-15 and JDK-11 last year. While Solaris support was (unfortunately) > abandoned in JDK-15, JDK-11 still supports and should further support > Solaris on both SPARC and x86 if my information is correct. > > I desperately need JDK-11 (and probably newer versions of Java) in order > to run several modern open-source tools. When trying to compile JDK-11 > on Solaris 11.4 SRU 31 on x86 according to [1] and [2], I run into the > following compile error problem: > > "./src/hotspot/cpu/x86/vm_version_x86.cpp", line 753: Error: > cpu_microcode_revision is not a member of os. > 1 Error(s) detected. > > The reason is quite obvious. The method > > os::cpu_microcode_revision() > > is not defined for the Solaris platform as JDK-8249672 does not alter > > src/hotspot/os_cpu/solaris_x86/os_solaris_x86.hpp > src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp > > The question is: How should we fix it? Is it allowed to call Solaris' > > /usr/sbin/ucodeadm -v > > and parse this binary's results or do we have to get the contents from > "/dev/ucode" (which seems to be the symlink to the pseudo-device > "/devices/pseudo/ucode at 0:ucode" and is accessed by ucodeadm) manually? > > Any help to make JDK 11 compiling on Solaris 11.4/x86 again would be > highly appreciated. Thank you very much in advance! > > Kind regards, > Steffen > > [1] https://blogs.oracle.com/solaris/building-openjdk-12-using-jdk-8 > [2] > > http://notallmicrosoft.blogspot.com/2020/04/building-openjdk-13-and-openjdk-14-on.html > From rehn at openjdk.java.net Mon Apr 19 08:22:35 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 19 Apr 2021 08:22:35 GMT Subject: RFR: 8257831: Suspend with handshakes [v12] In-Reply-To: References: Message-ID: <8SeoJUmAJV8_tx52dlAhwTVnlCYMrzqrT7yswrP07Fs=.908b8d5d-e60b-4c7d-8464-5c0c53a0cf3f@github.com> > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into SuspendInHandshake - Fixed DavidH second review - Fixed nits - Merge branch 'master' into SuspendInHandshake - Review fixes 4 - Fixed flag undef dep + spelling error - Obsolete unused flags - Review fixes 3 - Merge branch 'master' into SuspendInHandshake - Review fixes 2 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/e390e550...2c652f94 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=11 Stats: 1351 lines in 40 files changed: 273 ins; 882 del; 196 mod Patch: https://git.openjdk.java.net/jdk/pull/3191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191 PR: https://git.openjdk.java.net/jdk/pull/3191 From sgehwolf at openjdk.java.net Mon Apr 19 09:05:34 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 19 Apr 2021 09:05:34 GMT Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> Message-ID: On Thu, 25 Mar 2021 20:11:30 GMT, Anton Ostrouhhov wrote: > Hello! > Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`. > > This is my first contribution so please tell me if i am wrong somewhere. > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ > > On 16/04/2021 10:26 pm, Severin Gehwolf wrote: > > > On Fri, 16 Apr 2021 12:18:05 GMT, David Holmes wrote: > > > I'm not sure my, simple, point is getting through. Here's the cgroupv1 code: > > > ``` > > > /* cpu_quota > > > * > > > * Return the number of microseconds per period > > > * process is guaranteed to run. > > > * > > > * return: > > > * quota time in microseconds > > > * -1 for no quota > > > * OSCONTAINER_ERROR for not supported > > > */ > > > int CgroupV1Subsystem::cpu_quota() { > > > GET_CONTAINER_INFO(int, _cpu->controller(), "/cpu.cfs_quota_us", > > > "CPU Quota is: %d", "%d", quota); > > > return quota; > > > } > > > ``` > > > But if GET_CONTAINER_INFO doesn't find /cpu.cfs_quota_us the macro does "return OSCONTAINER_ERROR" which is "return -2". Yet the spec states that if there is no quota then -1 is returned, so why are we not returning -1? > > > > > > @dholmes-ora Because they're not equivalent. `-1` means, the system supports it in general, but no cgroups quota is in place. I.e. unlimited. For example A) `docker run --memory 200M ` on a cgroup capable system with all the kernel support should report the memory limit. B) `docker run `. Case B) would return -1. `-2` is usually something unexpected and means the system doesn't support it (be it by kernel config, the file not being present where a file is expected to be present, etc.). We want to distinguish those two cases. > > I don't see why the user cares about this distinction. That's how it's presented to the user (no distinction). This mapping is being done in function `CgroupSubsystem::active_processor_count` here: https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/cgroupSubsystem_linux.cpp#L442 I might have done a poor job at describing why we **internally** want to distinguish those two cases. Note that, we are discussing this in the context of a test failure. The test seems to assume that if cgroups is available (hotspot requires `memory`, `cpu`, `cpuset`, `cpuacct` and all seem present), the assumption is that `CONFIG_CFS_BANDWIDTH` is on too. > We might care for > logging purposes but that is different. It's this exact issue, is it not? The test uses container trace logging to assert quotas are being recognized (even for the plain cgroup case). It doesn't account for the `CONFIG_CFS_BANDWIDTH=no` case apparently. > There is no difference to the > end user between cgroups defines no quota and cgroups quotas are not > compiled into the kernel. Agreed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3206 From stuefe at openjdk.java.net Mon Apr 19 09:21:41 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 19 Apr 2021 09:21:41 GMT Subject: Integrated: JDK-8262165: NMT report should state how many callsites had been skipped In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 07:12:10 GMT, Thomas Stuefe wrote: > (This is a breakout from JDK-8261238, which seems to be stuck in review (https://github.com/openjdk/jdk/pull/2428). I factor out the display changes, which hopefully are non-controversial enough to get upstream easily.) > > NMT silently omits call sites in its report whose allocation rate is too small to get over certain, hidden, thresholds: > a) there is a hard wired threshold of 1K in the baseline collector > b) we also skip all sites whose size is less than what the unit is (eg scale=G, we skip all allocations < 1G > > NMT report should state how many call sites had been omitted. > > ---- > > The patch adds a counter in the NMT reporter to count omitted call sites, then prints that counter out. > > In base report, just a generic message is shown to notify the user that categories > scale are ignored: > > > thomas at mainframe$ jcmd Interl VM.native_memory scale=m > 2847: > > Native Memory Tracking: > > (Omitting categories weighting less than 1MB) > > Total: reserved=5540MB, committed=147MB > - Java Heap (reserved=3996MB, committed=34MB) > (mmap: reserved=3996MB, committed=34MB) > > > > In detail report, the total count of omitted call sites is displayed at the bottom: > > > thomas at mainframe$ jcmd Interl VM.native_memory scale=m detail > 2847: > > > > [0x00007f4e062e3e6b] os::reserve_memory(unsigned long, bool, MEMFLAGS)+0x16b > [0x00007f4e05ac4f47] MmapArrayAllocator::allocate(unsigned long, MEMFLAGS)+0x127 > [0x00007f4e05ac4cb2] G1FromCardCache::initialize(unsigned int)+0xe2 > [0x00007f4e05a863f1] G1CollectedHeap::initialize()+0x3c1 > (reserved=1MB, committed=1MB Type=GC) > > (183 call sites weighting less than 1MB each omitted.) > > > > Note: this patch only takes care of the sites omitted due to the scale threshold (b). It does not count how many sites had been omitted due to the baseline threshold (a). Since I still hope to remove that threshold completely with JDK-8261238, I did not put any work toward modifying the output here. > > ---- > > Tests: I manually ran runtime/NMT tests. This pull request has now been integrated. Changeset: 49b9e689 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/49b9e689 Stats: 53 lines in 2 files changed: 34 ins; 2 del; 17 mod 8262165: NMT report should state how many callsites had been skipped Reviewed-by: zgu, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/2687 From rehn at openjdk.java.net Mon Apr 19 09:26:04 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 19 Apr 2021 09:26:04 GMT Subject: RFR: 8257831: Suspend with handshakes [v12] In-Reply-To: <8SeoJUmAJV8_tx52dlAhwTVnlCYMrzqrT7yswrP07Fs=.908b8d5d-e60b-4c7d-8464-5c0c53a0cf3f@github.com> References: <8SeoJUmAJV8_tx52dlAhwTVnlCYMrzqrT7yswrP07Fs=.908b8d5d-e60b-4c7d-8464-5c0c53a0cf3f@github.com> Message-ID: On Mon, 19 Apr 2021 08:22:35 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into SuspendInHandshake > - Fixed DavidH second review > - Fixed nits > - Merge branch 'master' into SuspendInHandshake > - Review fixes 4 > - Fixed flag undef dep + spelling error > - Obsolete unused flags > - Review fixes 3 > - Merge branch 'master' into SuspendInHandshake > - Review fixes 2 > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/e390e550...2c652f94 Hi David, > I have gone through everything again in detail. A few comments on comments and a couple of details I'm still not really clear on. > I hope I made things more clear. > A couple of small renaming requests, but otherwise this is good to go - with the caveat of a future RFE to clear up the suspend-while-locking implementations so things are more cleanly encapsulated. > Yes, good. Fixed what I could in this commit, also fixed merged conflict. Thanks, Robbin > Thanks, > David ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From vlivanov at openjdk.java.net Mon Apr 19 13:22:34 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 19 Apr 2021 13:22:34 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 22:50:39 GMT, Vladimir Ivanov wrote: > `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. > > The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. > > Proposed fix is to start the search from the frame reported by `os::current_frame()`. > > Testing: > - [x] failing test > - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` Thanks for the review, David. > I'm always concerned that the correct use of "current frame" can depend on the presence or absence of inlining. So it is never clear to me that changes like this do not simply switch the set of contexts where this code is correct, based on the problem being solved today. In this particular case, `trace_method_handle_stub` is always called from generated code which sets up the frame being looked for. So, irrespective of the decisions being made by the native compiler, if there's enough info to traverse the native stack, the proper frame will be found. As an alternative solution, the code can be migrated away from `os::current_frame()` and the caller be obliged to pass stack frame info as an argument instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From vlivanov at openjdk.java.net Mon Apr 19 13:50:37 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 19 Apr 2021 13:50:37 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 In-Reply-To: <2_xzvM3b_0D2QgN9Ne6bMoHW2CigySF8_JE-L_Au0Ok=.b699d607-2431-419c-b427-4fac2699b1b4@github.com> References: <2_xzvM3b_0D2QgN9Ne6bMoHW2CigySF8_JE-L_Au0Ok=.b699d607-2431-419c-b427-4fac2699b1b4@github.com> Message-ID: On Sat, 17 Apr 2021 05:35:29 GMT, David Holmes wrote: >> `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. >> >> The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. >> >> Proposed fix is to start the search from the frame reported by `os::current_frame()`. >> >> Testing: >> - [x] failing test >> - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` > > src/hotspot/cpu/x86/methodHandles_x86.cpp line 558: > >> 556: FrameValues values; >> 557: >> 558: frame cur_frame = os::current_frame(); // reports caller's frame! > > It is unclear what "caller" is relative to in that comment - is it the caller of os::current_frame() as seen by os::current_frame(), or is it the caller of the current method that is invoking os::current_frame() ? As opposed to "current C frame", it is about "caller's C frame" ;-) I'll think about a way to make the comment less ambiguous. ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From pchilanomate at openjdk.java.net Mon Apr 19 15:12:06 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 19 Apr 2021 15:12:06 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() Message-ID: Hi, Please review this small fix. Method check_safepoint_and_suspend_for_native_trans() can just be removed and the code moved directly to check_special_condition_for_native_trans(). The other caller, transition_from_native(), can also just call SafepointMechanism::process_if_requested_with_exit_check() after transitioning to _thread_in_native_trans. Since that removes the only caller of is_suspend_after_native() I also removed it. I also made a small fix to has_special_runtime_exit_condition(). The compilers were generating three different comparisons for _suspend_flags instead of combining the constant values and doing a single one (I checked this with gcc 10.2 on linux and clang-12 on macos). The extra code was preventing inlining on some cases. For instance, on a Linux release build with gcc 10.2, for the ThreadInVMfromNative constructor, transition_from_native() was being inlined but not process_if_requested_with_exit_check(), so we still required a call for the fast case. The small change to has_special_runtime_exit_condition() fixed that. Tested in mach5 tiers1-2. Thanks, Patricio ------------- Commit messages: - fix has_special_runtime_exit_condition() to favor inlining - remove is_suspend_after_native() - v1 Changes: https://git.openjdk.java.net/jdk/pull/3548/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3548&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265327 Stats: 38 lines in 3 files changed: 6 ins; 25 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3548/head:pull/3548 PR: https://git.openjdk.java.net/jdk/pull/3548 From gziemski at openjdk.java.net Mon Apr 19 16:03:51 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 19 Apr 2021 16:03:51 GMT Subject: RFR: JDK-8261238: NMT should not limit baselining by size threshold [v5] In-Reply-To: <-lC9Ton50BkMMCrq3L21QVM6ywOgRrQl5sHXDKMzWpI=.99ec02eb-8695-4422-8152-0b1473a14e8c@github.com> References: <-lC9Ton50BkMMCrq3L21QVM6ywOgRrQl5sHXDKMzWpI=.99ec02eb-8695-4422-8152-0b1473a14e8c@github.com> Message-ID: <4MIqmF_TbTMVhWnHSG5SegtWtUUd73ARTp5bVzKPLVY=.d2a0ebfe-a536-47a6-87ff-0e8509a16279@github.com> On Tue, 23 Feb 2021 07:14:04 GMT, Thomas Stuefe wrote: >> NMT is a very useful tool to detect memory leaks. Its easy to use, relatively cheap and requires almost zero setup. >> >> But it artificially limits output to call sites with >1K total memory consumption. That is not helpful, as it confuses the developer and obscures possible memory leaks. It also introduces subtle display errors in that callsites suddenly seem to appear, when comparing to the baseline, with a load of >1K when in fact they had been there already when the baseline was taken. >> >> I propose to remove the 1K limit completely. This will marginally increase the costs of taking "detail" NMT reports by about 210K for a single report, 420K for a report done using a baseline. >> >> If this is really a problem preventing us from getting more precise NMT output (really?) there are possibilities to decrease the cost again by sharing call stacks by reference instead of copying them around. I have a patch in work which does just that (https://bugs.openjdk.java.net/browse/JDK-8261491), but I honestly think adding 200-400K *temporarily* during NMT detail reporting would not be such a big deal. > > Thomas Stuefe 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 > - Split out display changes > - Exclude zero-sized regions from baseline > - Start Would it be easier for everyone to accept this change if you introduced a runtime flag to control the threshold size, and left it at 1K by default to match the current behavior? This way the default behavior does not change, but those who care can tweak it at runtime all the way to 0 to get the use case they want. ------------- PR: https://git.openjdk.java.net/jdk/pull/2428 From minqi at openjdk.java.net Mon Apr 19 16:22:41 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 19 Apr 2021 16:22:41 GMT Subject: RFR: 8264569: Remove obsolete error messages from CDSTestUtils.java Message-ID: Hi, Please review this simple change to remove check messages which no longer exist in vm output. Tests: teri1,teir2,tier3,tier4 Thanks Yumin ------------- Commit messages: - 8264569: Remove obsolete error messages from CDSTestUtils.java Changes: https://git.openjdk.java.net/jdk/pull/3573/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3573&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264569 Stats: 13 lines in 1 file changed: 1 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3573.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3573/head:pull/3573 PR: https://git.openjdk.java.net/jdk/pull/3573 From iklam at openjdk.java.net Mon Apr 19 16:55:38 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 19 Apr 2021 16:55:38 GMT Subject: RFR: 8264569: Remove obsolete error messages from CDSTestUtils.java In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 16:15:00 GMT, Yumin Qi wrote: > Hi, Please review this simple change to remove check messages which no longer exist in vm output. > > Tests: teri1,teir2,tier3,tier4 > > Thanks > Yumin LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3573 From yyang at openjdk.java.net Mon Apr 19 16:57:36 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 19 Apr 2021 16:57:36 GMT Subject: Integrated: 8265285: Unnecessary inclusion of bytecodeHistogram.hpp In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 03:08:22 GMT, Yi Yang wrote: > Remove unnecessary inclusion of bytecodeHistogram.hpp This pull request has now been integrated. Changeset: 235daea0 Author: Yi Yang Committer: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/235daea0 Stats: 8 lines in 8 files changed: 3 ins; 5 del; 0 mod 8265285: Unnecessary inclusion of bytecodeHistogram.hpp Reviewed-by: dholmes, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3530 From minqi at openjdk.java.net Mon Apr 19 17:09:33 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 19 Apr 2021 17:09:33 GMT Subject: RFR: 8264569: Remove obsolete error messages from CDSTestUtils.java In-Reply-To: References: Message-ID: <5p6lc9UwiqmjQxhDhllSe4kq7x9JlPy9jne67QCxxto=.a0d7db20-1566-49bf-901c-a37aa23ba03c@github.com> On Mon, 19 Apr 2021 16:52:45 GMT, Ioi Lam wrote: >> Hi, Please review this simple change to remove check messages which no longer exist in vm output. >> >> Tests: teri1,teir2,tier3,tier4 >> >> Thanks >> Yumin > > LGTM. @iklam Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3573 From minqi at openjdk.java.net Mon Apr 19 17:09:34 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 19 Apr 2021 17:09:34 GMT Subject: Integrated: 8264569: Remove obsolete error messages from CDSTestUtils.java In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 16:15:00 GMT, Yumin Qi wrote: > Hi, Please review this simple change to remove check messages which no longer exist in vm output. > > Tests: teri1,teir2,tier3,tier4 > > Thanks > Yumin This pull request has now been integrated. Changeset: b703e0a4 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/b703e0a4 Stats: 13 lines in 1 file changed: 1 ins; 9 del; 3 mod 8264569: Remove obsolete error messages from CDSTestUtils.java Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3573 From iklam at openjdk.java.net Mon Apr 19 17:15:35 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 19 Apr 2021 17:15:35 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive In-Reply-To: References: Message-ID: <4nqaN5hyd5xTrspEcHcVlk2HSRet9t-LCtvLQUzycOY=.5ed2cca3-ccec-476c-9939-0d9cf1b67f75@github.com> On Wed, 14 Apr 2021 00:14:46 GMT, Calvin Cheung wrote: > Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. > During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. > Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. > > Passed tiers 1,2,3,4 tests on mach5. Looks good to me. Some suggestions for comments and performance improvement. src/hotspot/share/classfile/verifier.cpp line 289: > 287: // which the verifier can't understand. > 288: // Bytecodes for shared old classes can be verified because they have > 289: // not been rewritten. Maybe put the above 2 lines under line 290, and change "can be" to "should be"? // However, bytecodes for shared old classes should be verified because they have // not been rewritten. src/hotspot/share/interpreter/rewriter.cpp line 572: > 570: void Rewriter::rewrite(InstanceKlass* klass, TRAPS) { > 571: if (klass->is_shared()) { > 572: assert(!klass->is_rewritten(), "rewritten shared classes cannot be rewritten again"); Also add assert(MetaspaceShared::is_old_class(klass), "only shared old classes aren't rewritten"); src/hotspot/share/oops/constantPool.cpp line 142: > 140: it->push(&_tags, MetaspaceClosure::_writable); > 141: if (!pool_holder()->is_rewritten()) { > 142: it->push(&_cache, MetaspaceClosure::_writable); This shouldn't be necessary. All ConstantPoolCache are allocated in RW space by default. src/hotspot/share/oops/klassVtable.cpp line 54: > 52: > 53: bool klassVtable::is_preinitialized_vtable() { > 54: return _klass->is_shared() && !MetaspaceShared::remapped_readwrite() && !MetaspaceShared::is_old_class(ik()); Maybe we can avoid calling `MetaspaceShared::is_old_class()` by adding an extra bit into klass.hpp: #if INCLUDE_CDS // Flags of the current shared class. u2 _shared_class_flags; enum { _archived_lambda_proxy_is_available = 2, _has_value_based_class_annotation = 4, + _is_shared_old_klass = 8 }; #endif ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3479 From hseigel at openjdk.java.net Mon Apr 19 17:25:02 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 19 Apr 2021 17:25:02 GMT Subject: RFR: 8265017: runtime/HiddenClasses/StressHiddenClasses.java timed out on Win* OCI Message-ID: Please review this small test change to try to prevent test StressHiddenClasses,java from timing out. The change increases the test's timeout and prints some output the could be useful in future timeouts. The test was run over 1000 times on Windows with this change without any failures. Thanks, Harold ------------- Commit messages: - 8265017: runtime/HiddenClasses/StressHiddenClasses.java timed out on Win* OCI Changes: https://git.openjdk.java.net/jdk/pull/3574/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3574&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265017 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3574/head:pull/3574 PR: https://git.openjdk.java.net/jdk/pull/3574 From dcubed at openjdk.java.net Mon Apr 19 18:06:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Apr 2021 18:06:31 GMT Subject: RFR: 8265463: ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp Message-ID: A couple of trivial fixes to ProblemList a couple of tests in -Xcomp configs: - JDK-8265463 ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp - JDK-8265464 ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs ------------- Commit messages: - 8265464: ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs - 8265463: ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp Changes: https://git.openjdk.java.net/jdk/pull/3575/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3575&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265463 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3575.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3575/head:pull/3575 PR: https://git.openjdk.java.net/jdk/pull/3575 From pchilanomate at openjdk.java.net Mon Apr 19 18:22:30 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 19 Apr 2021 18:22:30 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 15:25:16 GMT, Daniel D. Daugherty wrote: >> If we process the async suspension handshake we can go to safepoint. >> And before safepoint we must drop the tty lock. > > Is this worth a comment above the `break_tty_lock_for_safepoint()` call? I also thought we could remove this since we are already releasing it in the ThreadInVMForHandshake constructor above. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From mikael at openjdk.java.net Mon Apr 19 18:41:07 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 19 Apr 2021 18:41:07 GMT Subject: RFR: 8265463: ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp In-Reply-To: References: Message-ID: <5twxFUikmLcAtUEypKZbYMUmg89n6cmLz5i7KSoiB9s=.adbdff2b-df25-4ae6-be6a-6d0419a7be57@github.com> On Mon, 19 Apr 2021 17:52:17 GMT, Daniel D. Daugherty wrote: > A couple of trivial fixes to ProblemList a couple of tests in -Xcomp configs: > > - JDK-8265463 ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp > - JDK-8265464 ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3575 From dcubed at openjdk.java.net Mon Apr 19 18:54:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Apr 2021 18:54:04 GMT Subject: RFR: 8265463: ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp In-Reply-To: <5twxFUikmLcAtUEypKZbYMUmg89n6cmLz5i7KSoiB9s=.adbdff2b-df25-4ae6-be6a-6d0419a7be57@github.com> References: <5twxFUikmLcAtUEypKZbYMUmg89n6cmLz5i7KSoiB9s=.adbdff2b-df25-4ae6-be6a-6d0419a7be57@github.com> Message-ID: On Mon, 19 Apr 2021 18:38:40 GMT, Mikael Vidstedt wrote: >> A couple of trivial fixes to ProblemList a couple of tests in -Xcomp configs: >> >> - JDK-8265463 ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp >> - JDK-8265464 ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3575 From dcubed at openjdk.java.net Mon Apr 19 18:54:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Apr 2021 18:54:05 GMT Subject: Integrated: 8265463: ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 17:52:17 GMT, Daniel D. Daugherty wrote: > A couple of trivial fixes to ProblemList a couple of tests in -Xcomp configs: > > - JDK-8265463 ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp > - JDK-8265464 ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs This pull request has now been integrated. Changeset: 39907136 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/39907136 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8265463: ProblemList vmTestbase/vm/mlvm/mixed/stress/regression/b6969574/INDIFY_Test.java on Win-X64 -Xcomp 8265464: ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 in -Xcomp configs Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/3575 From kvn at openjdk.java.net Mon Apr 19 19:15:06 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 19 Apr 2021 19:15:06 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 09:46:17 GMT, Doug Simon wrote: >> While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. >> >> In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. > > Doug Simon 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: > > avoid use of a lambda in JVMCI initialization Please, update copyright years in files you touched. src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 118: > 116: decl(STXR_PREFETCH, "stxr_prefetch", 29) \ > 117: decl(A53MAC, "a53mac", 30) > 118: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = (1 << bit), Add empty line before to separate `CPU_FEATURE_FLAGS` macro. src/hotspot/cpu/x86/vmStructs_x86.hpp line 45: > 43: > 44: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id) > 45: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT) Do we need to keep `VM_LONG_CONSTANTS_CPU` after you removed its body here and in vmStructs_jvmci.cpp? What about `VM_INT_CONSTANTS_CPU` here? vmStructs_jvmci.cpp duplicates it. src/hotspot/cpu/x86/vm_version_x86.hpp line 363: > 361: decl(AVX512_VBMI, "avx512_vbmi", 45) /* Vector BMI instructions */ \ > 362: decl(HV, "hv", 46) /* Hypervisor instructions */ > 363: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = (1ULL << bit), Add empty line before it to separate `CPU_FEATURE_FLAGS` macro more clear. src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 753: > 751: > 752: #define DECLARE_INT_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_INT_CONSTANT_ENTRY(VM_Version::CPU_##id) > 753: #define VM_INT_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_INT_CPU_FEATURE_CONSTANT) Missing `#undef DECLARE_INT_CPU_FEATURE_CONSTANT`. src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 769: > 767: > 768: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id) > 769: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT) Missing `#undef DECLARE_LONG_CPU_FEATURE_CONSTANT`. src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java line 66: > 64: long bitMask = e.getValue(); > 65: String key = e.getKey(); > 66: if (key.startsWith("VM_Version::CPU_")) { As I understand this code, it goes over `constants` values passed from VM and Trying to map them to `enumType`. It catches cases when a value is missing in `enumType`. What about case when `enumType` has `extra` value which is not defined in `constants`? ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dcubed at openjdk.java.net Mon Apr 19 19:31:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Apr 2021 19:31:34 GMT Subject: RFR: 8257831: Suspend with handshakes [v12] In-Reply-To: <8SeoJUmAJV8_tx52dlAhwTVnlCYMrzqrT7yswrP07Fs=.908b8d5d-e60b-4c7d-8464-5c0c53a0cf3f@github.com> References: <8SeoJUmAJV8_tx52dlAhwTVnlCYMrzqrT7yswrP07Fs=.908b8d5d-e60b-4c7d-8464-5c0c53a0cf3f@github.com> Message-ID: <7s-mPFHx9T7eKI6WH0lZbE3eA6MsEUoGcBNPcjLfkDI=.066b8585-1dd0-4c9f-ba4c-c6736eea8b8a@github.com> On Mon, 19 Apr 2021 08:22:35 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into SuspendInHandshake > - Fixed DavidH second review > - Fixed nits > - Merge branch 'master' into SuspendInHandshake > - Review fixes 4 > - Fixed flag undef dep + spelling error > - Obsolete unused flags > - Review fixes 3 > - Merge branch 'master' into SuspendInHandshake > - Review fixes 2 > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/e390e550...2c652f94 One minor nit from a review of incremental v10. Still thumbs up. src/hotspot/share/runtime/handshake.cpp line 636: > 634: JavaThread* thread_current = thr->as_Java_thread(); > 635: assert(thread_current == Thread::current(), "Must be self executed."); > 636: thread_current->handshake_state()->do_self_suspend(); nit - When you know it is the "current" thread, @dholmes-ora has been using just `current` and not `current_thread` or `thread_current`. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From dnsimon at openjdk.java.net Mon Apr 19 19:38:08 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 19:38:08 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 18:57:37 GMT, Vladimir Kozlov wrote: >> Doug Simon 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: >> >> avoid use of a lambda in JVMCI initialization > > src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 118: > >> 116: decl(STXR_PREFETCH, "stxr_prefetch", 29) \ >> 117: decl(A53MAC, "a53mac", 30) >> 118: #define DECLARE_CPU_FEATURE_FLAG(id, name, bit) CPU_##id = (1 << bit), > > Add empty line before to separate `CPU_FEATURE_FLAGS` macro. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dnsimon at openjdk.java.net Mon Apr 19 19:42:05 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 19:42:05 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 18:58:46 GMT, Vladimir Kozlov wrote: >> Doug Simon 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: >> >> avoid use of a lambda in JVMCI initialization > > src/hotspot/cpu/x86/vmStructs_x86.hpp line 45: > >> 43: >> 44: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id) >> 45: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT) > > Do we need to keep `VM_LONG_CONSTANTS_CPU` after you removed its body here and in vmStructs_jvmci.cpp? > > What about `VM_INT_CONSTANTS_CPU` here? vmStructs_jvmci.cpp duplicates it. `vmStructs.cpp` and `vmStructs_jvmci.cpp` are disjoint. This file (i.e. `vmStructs_x86.hpp`) is only used by `vmStructs.cpp`. `vmStructs.cpp` expects all macros such as `VM_LONG_CONSTANTS_CPU` to be defined. `vmStructs_jvmci.cpp` will provide a dummy definition for missing macros. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dcubed at openjdk.java.net Mon Apr 19 19:45:12 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Apr 2021 19:45:12 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 16:24:53 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this small fix. Method check_safepoint_and_suspend_for_native_trans() can just be removed and the code moved directly to check_special_condition_for_native_trans(). The other caller, transition_from_native(), can also just call SafepointMechanism::process_if_requested_with_exit_check() after transitioning to _thread_in_native_trans. Since that removes the only caller of is_suspend_after_native() I also removed it. > I also made a small fix to has_special_runtime_exit_condition(). The compilers were generating three different comparisons for _suspend_flags instead of combining the constant values and doing a single one (I checked this with gcc 10.2 on linux and clang-12 on macos). The extra code was preventing inlining on some cases. For instance, on a Linux release build with gcc 10.2, for the ThreadInVMfromNative constructor, transition_from_native() was being inlined but not process_if_requested_with_exit_check(), so we still required a call for the fast case. The small change to has_special_runtime_exit_condition() fixed that. > Tested in mach5 tiers1-2. > > Thanks, > > Patricio One nit and one question. Thumbs up. src/hotspot/share/runtime/thread.cpp line 2150: > 2148: // pending, when _suspend_flags is non-zero or when we need to process a stack > 2149: // watermark. Also check for pending async exceptions (except unsafe access error). > 2150: // Note only the native==>Java barriers can call this function and when nit typo: s/and when/when/ src/hotspot/share/runtime/thread.hpp line 1325: > 1323: // under SR_lock in java_suspend_self(). > 1324: return (_special_runtime_exit_condition != _no_async_condition) || > 1325: (_suspend_flags & (_external_suspend | _obj_deopt JFR_ONLY(| _trace_flag))) != 0; I don't see this change mentioned in the bug report and it's not obvious why you're changing this code. Also, I think this is going to conflict with @robehn fix for JDK-8257831. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3548 From dnsimon at openjdk.java.net Mon Apr 19 19:49:07 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 19:49:07 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:00:09 GMT, Vladimir Kozlov wrote: >> Doug Simon 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: >> >> avoid use of a lambda in JVMCI initialization > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 753: > >> 751: >> 752: #define DECLARE_INT_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_INT_CONSTANT_ENTRY(VM_Version::CPU_##id) >> 753: #define VM_INT_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_INT_CPU_FEATURE_CONSTANT) > > Missing `#undef DECLARE_INT_CPU_FEATURE_CONSTANT`. No, it must stay defined up to the point `VM_INT_CPU_FEATURE_CONSTANTS` is used. Since this is a `.cpp` file, it's ok to leave it defined. > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 769: > >> 767: >> 768: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id) >> 769: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT) > > Missing `#undef DECLARE_LONG_CPU_FEATURE_CONSTANT`. So comment as for `DECLARE_INT_CPU_FEATURE_CONSTANT`. > src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java line 66: > >> 64: long bitMask = e.getValue(); >> 65: String key = e.getKey(); >> 66: if (key.startsWith("VM_Version::CPU_")) { > > As I understand this code, it goes over `constants` values passed from VM and Trying to map them to `enumType`. It catches cases when a value is missing in `enumType`. What about case when `enumType` has `extra` value which is not defined in `constants`? We could warn about that but cannot remove it without breaking backwards capability for JVMCI wrt Graal. Such a deleted capability will simply be seen as "not supported" by Graal. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dnsimon at openjdk.java.net Mon Apr 19 19:56:45 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 19:56:45 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v4] In-Reply-To: References: Message-ID: > While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. Doug Simon has updated the pull request incrementally with two additional commits since the last revision: - updated date in copyright - added blank lines after macros ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3558/files - new: https://git.openjdk.java.net/jdk/pull/3558/files/124019d7..c6be1437 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=02-03 Stats: 11 lines in 10 files changed: 2 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3558/head:pull/3558 PR: https://git.openjdk.java.net/jdk/pull/3558 From kvn at openjdk.java.net Mon Apr 19 20:05:06 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 19 Apr 2021 20:05:06 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:38:52 GMT, Doug Simon wrote: >> src/hotspot/cpu/x86/vmStructs_x86.hpp line 45: >> >>> 43: >>> 44: #define DECLARE_LONG_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_LONG_CONSTANT_ENTRY(VM_Version::CPU_##id) >>> 45: #define VM_LONG_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_LONG_CPU_FEATURE_CONSTANT) >> >> Do we need to keep `VM_LONG_CONSTANTS_CPU` after you removed its body here and in vmStructs_jvmci.cpp? >> >> What about `VM_INT_CONSTANTS_CPU` here? vmStructs_jvmci.cpp duplicates it. > > `vmStructs.cpp` and `vmStructs_jvmci.cpp` are disjoint. This file (i.e. `vmStructs_x86.hpp`) is only used by `vmStructs.cpp`. > `vmStructs.cpp` expects all macros such as `VM_LONG_CONSTANTS_CPU` to be defined. > `vmStructs_jvmci.cpp` will provide a dummy definition for missing macros. Got it. Even so they are empty everywhere :( >> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 753: >> >>> 751: >>> 752: #define DECLARE_INT_CPU_FEATURE_CONSTANT(id, name, bit) GENERATE_VM_INT_CONSTANT_ENTRY(VM_Version::CPU_##id) >>> 753: #define VM_INT_CPU_FEATURE_CONSTANTS CPU_FEATURE_FLAGS(DECLARE_INT_CPU_FEATURE_CONSTANT) >> >> Missing `#undef DECLARE_INT_CPU_FEATURE_CONSTANT`. > > No, it must stay defined up to the point `VM_INT_CPU_FEATURE_CONSTANTS` is used. Since this is a `.cpp` file, it's ok to leave it defined. I see. >> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java line 66: >> >>> 64: long bitMask = e.getValue(); >>> 65: String key = e.getKey(); >>> 66: if (key.startsWith("VM_Version::CPU_")) { >> >> As I understand this code, it goes over `constants` values passed from VM and Trying to map them to `enumType`. It catches cases when a value is missing in `enumType`. What about case when `enumType` has `extra` value which is not defined in `constants`? > > We could warn about that but cannot remove it without breaking backwards capability for JVMCI wrt Graal. Such a deleted capability will simply be seen as "not supported" by Graal. Okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From kvn at openjdk.java.net Mon Apr 19 20:05:05 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 19 Apr 2021 20:05:05 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v4] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:56:45 GMT, Doug Simon wrote: >> While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. >> >> In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. > > Doug Simon has updated the pull request incrementally with two additional commits since the last revision: > > - updated date in copyright > - added blank lines after macros You need review from Runtime group too. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3558 From dcubed at openjdk.java.net Mon Apr 19 20:06:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Apr 2021 20:06:04 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 22:50:39 GMT, Vladimir Ivanov wrote: > `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. > > The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. > > Proposed fix is to start the search from the frame reported by `os::current_frame()`. > > Testing: > - [x] failing test > - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` Sorry, this change isn't make sense to me yet. src/hotspot/cpu/x86/methodHandles_x86.cpp line 565: > 563: // Assumes saved_regs comes from a pusha in the trace_calling_frame. > 564: assert(cur_frame.sp() < saved_regs, "registers not saved on stack ?"); > 565: frame trace_calling_frame = cur_frame; Since I'm expecting `cur_frame` to be `trace_method_handle_stub`, the original code makes sense to me since I want the sender for `trace_method_handle_stub`. If `cur_frame` is not `trace_method_handle_stub`, then I definitely don't understand the code at L558 so I definitely don't understand the comment that you added either. ------------- Changes requested by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3554 From dcubed at openjdk.java.net Mon Apr 19 20:06:06 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Apr 2021 20:06:06 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 In-Reply-To: References: <2_xzvM3b_0D2QgN9Ne6bMoHW2CigySF8_JE-L_Au0Ok=.b699d607-2431-419c-b427-4fac2699b1b4@github.com> Message-ID: On Mon, 19 Apr 2021 13:46:57 GMT, Vladimir Ivanov wrote: >> src/hotspot/cpu/x86/methodHandles_x86.cpp line 558: >> >>> 556: FrameValues values; >>> 557: >>> 558: frame cur_frame = os::current_frame(); // reports caller's frame! >> >> It is unclear what "caller" is relative to in that comment - is it the caller of os::current_frame() as seen by os::current_frame(), or is it the caller of the current method that is invoking os::current_frame() ? > > As opposed to "current C frame", it is about "caller's C frame" ;-) > > I'll think about a way to make the comment less ambiguous. It's always difficult to document a call to `os::current_frame()`. I ran into this all the time when working with `AsyncGetCallTrace()`... When I see the comment that you wrote here: - I expect that comment to apply to the context in which I find that comment. - In this case, I expect the `os::current_frame()` to return the caller's frame and since that comment is in `trace_method_handle_stub` AND that's the code that's calling `os::current_frame()`, I expect the "caller's frame" to mean `trace_method_handle_stub`. If that's what you mean, then we're okay from my POV. If that's not what you mean, then I'm confused. ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From dcubed at openjdk.java.net Mon Apr 19 20:38:03 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Apr 2021 20:38:03 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:08:52 GMT, Daniel D. Daugherty wrote: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Ping! Any takers for the new test review? ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From vlivanov at openjdk.java.net Mon Apr 19 21:10:04 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 19 Apr 2021 21:10:04 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 In-Reply-To: References: <2_xzvM3b_0D2QgN9Ne6bMoHW2CigySF8_JE-L_Au0Ok=.b699d607-2431-419c-b427-4fac2699b1b4@github.com> Message-ID: On Mon, 19 Apr 2021 19:56:49 GMT, Daniel D. Daugherty wrote: >> As opposed to "current C frame", it is about "caller's C frame" ;-) >> >> I'll think about a way to make the comment less ambiguous. > > It's always difficult to document a call to `os::current_frame()`. > I ran into this all the time when working with `AsyncGetCallTrace()`... > > When I see the comment that you wrote here: > > - I expect that comment to apply to the context in which I find that comment. > - In this case, I expect the `os::current_frame()` to return the caller's frame and since that comment is in `trace_method_handle_stub` AND that's the code that's calling `os::current_frame()`, I expect the "caller's frame" to mean `trace_method_handle_stub`. > > If that's what you mean, then we're okay from my POV. If that's not what you mean, then I'm confused. I can completely remove the comment. It turns out any reference to "current"/"caller"/"callee" doesn't make much sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From vlivanov at openjdk.java.net Mon Apr 19 21:10:05 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 19 Apr 2021 21:10:05 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 20:02:30 GMT, Daniel D. Daugherty wrote: >> `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. >> >> The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. >> >> Proposed fix is to start the search from the frame reported by `os::current_frame()`. >> >> Testing: >> - [x] failing test >> - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` > > src/hotspot/cpu/x86/methodHandles_x86.cpp line 565: > >> 563: // Assumes saved_regs comes from a pusha in the trace_calling_frame. >> 564: assert(cur_frame.sp() < saved_regs, "registers not saved on stack ?"); >> 565: frame trace_calling_frame = cur_frame; > > Since I'm expecting `cur_frame` to be `trace_method_handle_stub`, > the original code makes sense to me since I want the sender for > `trace_method_handle_stub`. > > If `cur_frame` is not `trace_method_handle_stub`, then I definitely > don't understand the code at L558 so I definitely don't understand > the comment that you added either. No, unfortunately, it's not `trace_method_handle_stub`. It has `trace_method_handle_stub` call in tail position, so even when inlining doesn't happen, the call may be turned into a tail-call. And that's what actually happens after 8264358. So, there's no stack frame for `trace_method_handle_stub` left when `os::current_frame()` is performed. The next frame under top frame corresponds to the caller of `trace_method_handle_stub` in generated code (which contains registers and has to be printed). And it's the one which is returned by `os::current_frame()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From vlivanov at openjdk.java.net Mon Apr 19 21:26:04 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 19 Apr 2021 21:26:04 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 In-Reply-To: References: <2_xzvM3b_0D2QgN9Ne6bMoHW2CigySF8_JE-L_Au0Ok=.b699d607-2431-419c-b427-4fac2699b1b4@github.com> Message-ID: <9063lFKlCv0VeB8ecsOGSEMOYF52_HSZjkxobaa1kRU=.c26fc2ed-f228-4b85-9f86-170addcaf63f@github.com> On Mon, 19 Apr 2021 21:07:24 GMT, Vladimir Ivanov wrote: >> It's always difficult to document a call to `os::current_frame()`. >> I ran into this all the time when working with `AsyncGetCallTrace()`... >> >> When I see the comment that you wrote here: >> >> - I expect that comment to apply to the context in which I find that comment. >> - In this case, I expect the `os::current_frame()` to return the caller's frame and since that comment is in `trace_method_handle_stub` AND that's the code that's calling `os::current_frame()`, I expect the "caller's frame" to mean `trace_method_handle_stub`. >> >> If that's what you mean, then we're okay from my POV. If that's not what you mean, then I'm confused. > > I can completely remove the comment. It turns out any reference to "current"/"caller"/"callee" doesn't make much sense. Why I thought that explicitly calling that it's the "caller's frame" makes things clearer: (1) the code explicitly is written in such a way to skip any intermediate frames; (2) all users are in generated code. So, we know for sure there's a separate frame on the stack (which contains register values) and it differs from the top one. The bug is that we can't skip the frame returned by `os::current_frame()` because it doesn't return the top frame on the stack, but the next one. ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From patricio.chilano.mateo at oracle.com Mon Apr 19 21:33:06 2021 From: patricio.chilano.mateo at oracle.com (patricio.chilano.mateo at oracle.com) Date: Mon, 19 Apr 2021 18:33:06 -0300 Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() In-Reply-To: References: Message-ID: <3d2307a2-36d8-a1f1-afba-3338b1bdd1b5@oracle.com> Hi Dan, Thanks for looking at this. On 4/19/21 4:45 PM, Daniel D.Daugherty wrote: > On Fri, 16 Apr 2021 16:24:53 GMT, Patricio Chilano Mateo wrote: > >> Hi, >> >> Please review this small fix. Method check_safepoint_and_suspend_for_native_trans() can just be removed and the code moved directly to check_special_condition_for_native_trans(). The other caller, transition_from_native(), can also just call SafepointMechanism::process_if_requested_with_exit_check() after transitioning to _thread_in_native_trans. Since that removes the only caller of is_suspend_after_native() I also removed it. >> I also made a small fix to has_special_runtime_exit_condition(). The compilers were generating three different comparisons for _suspend_flags instead of combining the constant values and doing a single one (I checked this with gcc 10.2 on linux and clang-12 on macos). The extra code was preventing inlining on some cases. For instance, on a Linux release build with gcc 10.2, for the ThreadInVMfromNative constructor, transition_from_native() was being inlined but not process_if_requested_with_exit_check(), so we still required a call for the fast case. The small change to has_special_runtime_exit_condition() fixed that. >> Tested in mach5 tiers1-2. >> >> Thanks, >> >> Patricio > One nit and one question. > > Thumbs up. > > src/hotspot/share/runtime/thread.cpp line 2150: > >> 2148: // pending, when _suspend_flags is non-zero or when we need to process a stack >> 2149: // watermark. Also check for pending async exceptions (except unsafe access error). >> 2150: // Note only the native==>Java barriers can call this function and when > nit typo: s/and when/when/ Fixed. > src/hotspot/share/runtime/thread.hpp line 1325: > >> 1323: // under SR_lock in java_suspend_self(). >> 1324: return (_special_runtime_exit_condition != _no_async_condition) || >> 1325: (_suspend_flags & (_external_suspend | _obj_deopt JFR_ONLY(| _trace_flag))) != 0; > I don't see this change mentioned in the bug report and it's > not obvious why you're changing this code. So before I made this change to has_special_runtime_exit_condition() I checked the generated code for the ThreadInVMfromNative constructor in libjvm.so and noticed we were making a call to process_if_requested_with_exit_check(), so it wasn't inlined as I was expecting. Then I checked the generated code for process_if_requested_with_exit_check() and saw these extra checks for _suspend_flags which were most likely making the method too big to be inlined. After this small fix I checked again and the call to process_if_requested_with_exit_check() was now also being inlined. I spotted this issue on a linux machine, compiling with gcc 10.2. I checked also on macos(compiling with clang 12) but everything was already inlined even without this change to has_special_runtime_exit_condition(). I will add this to the bug report. > Also, I think this > is going to conflict with @robehn fix for JDK-8257831. Right, is_external_suspend() will be gone with Robbin's change, so the single check will be just for is_trace_suspend() || is_obj_deopt_suspend(). I'll check with him to confirm when he will be integrating. Thanks! Patricio > ------------- > > Marked as reviewed by dcubed (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3548 From pchilanomate at openjdk.java.net Mon Apr 19 21:39:18 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 19 Apr 2021 21:39:18 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v2] In-Reply-To: References: Message-ID: > Hi, > > Please review this small fix. Method check_safepoint_and_suspend_for_native_trans() can just be removed and the code moved directly to check_special_condition_for_native_trans(). The other caller, transition_from_native(), can also just call SafepointMechanism::process_if_requested_with_exit_check() after transitioning to _thread_in_native_trans. Since that removes the only caller of is_suspend_after_native() I also removed it. > I also made a small fix to has_special_runtime_exit_condition(). The compilers were generating three different comparisons for _suspend_flags instead of combining the constant values and doing a single one (I checked this with gcc 10.2 on linux and clang-12 on macos). The extra code was preventing inlining on some cases. For instance, on a Linux release build with gcc 10.2, for the ThreadInVMfromNative constructor, transition_from_native() was being inlined but not process_if_requested_with_exit_check(), so we still required a call for the fast case. The small change to has_special_runtime_exit_condition() fixed that. > Tested in mach5 tiers1-2. > > Thanks, > > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: fix typo in comment for check_special_condition_for_native_trans ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3548/files - new: https://git.openjdk.java.net/jdk/pull/3548/files/a8744c07..aec3dd71 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3548&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3548&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3548/head:pull/3548 PR: https://git.openjdk.java.net/jdk/pull/3548 From dholmes at openjdk.java.net Mon Apr 19 21:47:25 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 19 Apr 2021 21:47:25 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers Message-ID: If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. Testing: tiers 1-3 Thanks, David ------------- Commit messages: - 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers Changes: https://git.openjdk.java.net/jdk/pull/3580/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3580&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265484 Stats: 44 lines in 4 files changed: 16 ins; 11 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/3580.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3580/head:pull/3580 PR: https://git.openjdk.java.net/jdk/pull/3580 From dcubed at openjdk.java.net Mon Apr 19 22:10:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Apr 2021 22:10:07 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 In-Reply-To: <9063lFKlCv0VeB8ecsOGSEMOYF52_HSZjkxobaa1kRU=.c26fc2ed-f228-4b85-9f86-170addcaf63f@github.com> References: <2_xzvM3b_0D2QgN9Ne6bMoHW2CigySF8_JE-L_Au0Ok=.b699d607-2431-419c-b427-4fac2699b1b4@github.com> <9063lFKlCv0VeB8ecsOGSEMOYF52_HSZjkxobaa1kRU=.c26fc2ed-f228-4b85-9f86-170addcaf63f@github.com> Message-ID: On Mon, 19 Apr 2021 21:22:53 GMT, Vladimir Ivanov wrote: >> I can completely remove the comment. It turns out any reference to "current"/"caller"/"callee" doesn't make much sense. > > Why I thought that explicitly calling that it's the "caller's frame" makes things clearer: > (1) the code explicitly is written in such a way to skip any intermediate frames; > (2) all users are in generated code. > > So, we know for sure there's a separate frame on the stack (which contains register values) and it differs from the top one. The bug is that we can't skip the frame returned by `os::current_frame()` because it doesn't return the top frame on the stack, but the next one. Removing the comment doesn't help the reader understand the code. Please replace the comment with something that accurately explains what happens from this `os::current_frame()` call site. ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From ccheung at openjdk.java.net Tue Apr 20 00:01:50 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 20 Apr 2021 00:01:50 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive [v2] In-Reply-To: References: Message-ID: > Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. > During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. > Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. > > Passed tiers 1,2,3,4 tests on mach5. Calvin Cheung 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 seven additional commits since the last revision: - review comments from @iklam - Merge branch 'master' into 8261090-store-old-classfiles - use is_written() instead of is_old_class() in constantPool.cpp - remove extraneous whitespace - Merge branch 'master' into 8261090-store-old-classfiles - add comments and some code simplification - 8261090: Store old classfiles in static CDS archive ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3479/files - new: https://git.openjdk.java.net/jdk/pull/3479/files/11fdb562..c93eaedd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3479&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3479&range=00-01 Stats: 31409 lines in 1112 files changed: 3184 ins; 24288 del; 3937 mod Patch: https://git.openjdk.java.net/jdk/pull/3479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3479/head:pull/3479 PR: https://git.openjdk.java.net/jdk/pull/3479 From ccheung at openjdk.java.net Tue Apr 20 00:01:58 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 20 Apr 2021 00:01:58 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive [v2] In-Reply-To: <4nqaN5hyd5xTrspEcHcVlk2HSRet9t-LCtvLQUzycOY=.5ed2cca3-ccec-476c-9939-0d9cf1b67f75@github.com> References: <4nqaN5hyd5xTrspEcHcVlk2HSRet9t-LCtvLQUzycOY=.5ed2cca3-ccec-476c-9939-0d9cf1b67f75@github.com> Message-ID: On Mon, 19 Apr 2021 17:02:48 GMT, Ioi Lam wrote: >> Calvin Cheung 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 seven additional commits since the last revision: >> >> - review comments from @iklam >> - Merge branch 'master' into 8261090-store-old-classfiles >> - use is_written() instead of is_old_class() in constantPool.cpp >> - remove extraneous whitespace >> - Merge branch 'master' into 8261090-store-old-classfiles >> - add comments and some code simplification >> - 8261090: Store old classfiles in static CDS archive > > src/hotspot/share/classfile/verifier.cpp line 289: > >> 287: // which the verifier can't understand. >> 288: // Bytecodes for shared old classes can be verified because they have >> 289: // not been rewritten. > > Maybe put the above 2 lines under line 290, and change "can be" to "should be"? > > > // However, bytecodes for shared old classes should be verified because they have > // not been rewritten. Fixed. > src/hotspot/share/interpreter/rewriter.cpp line 572: > >> 570: void Rewriter::rewrite(InstanceKlass* klass, TRAPS) { >> 571: if (klass->is_shared()) { >> 572: assert(!klass->is_rewritten(), "rewritten shared classes cannot be rewritten again"); > > Also add > > > assert(MetaspaceShared::is_old_class(klass), "only shared old classes aren't rewritten"); Fixed. > src/hotspot/share/oops/constantPool.cpp line 142: > >> 140: it->push(&_tags, MetaspaceClosure::_writable); >> 141: if (!pool_holder()->is_rewritten()) { >> 142: it->push(&_cache, MetaspaceClosure::_writable); > > This shouldn't be necessary. All ConstantPoolCache are allocated in RW space by default. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3479 From ccheung at openjdk.java.net Tue Apr 20 00:05:09 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 20 Apr 2021 00:05:09 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive [v2] In-Reply-To: <4nqaN5hyd5xTrspEcHcVlk2HSRet9t-LCtvLQUzycOY=.5ed2cca3-ccec-476c-9939-0d9cf1b67f75@github.com> References: <4nqaN5hyd5xTrspEcHcVlk2HSRet9t-LCtvLQUzycOY=.5ed2cca3-ccec-476c-9939-0d9cf1b67f75@github.com> Message-ID: On Mon, 19 Apr 2021 17:11:36 GMT, Ioi Lam wrote: >> Calvin Cheung 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 seven additional commits since the last revision: >> >> - review comments from @iklam >> - Merge branch 'master' into 8261090-store-old-classfiles >> - use is_written() instead of is_old_class() in constantPool.cpp >> - remove extraneous whitespace >> - Merge branch 'master' into 8261090-store-old-classfiles >> - add comments and some code simplification >> - 8261090: Store old classfiles in static CDS archive > > src/hotspot/share/oops/klassVtable.cpp line 54: > >> 52: >> 53: bool klassVtable::is_preinitialized_vtable() { >> 54: return _klass->is_shared() && !MetaspaceShared::remapped_readwrite() && !MetaspaceShared::is_old_class(ik()); > > Maybe we can avoid calling `MetaspaceShared::is_old_class()` by adding an extra bit into klass.hpp: > > > #if INCLUDE_CDS > // Flags of the current shared class. > u2 _shared_class_flags; > enum { > _archived_lambda_proxy_is_available = 2, > _has_value_based_class_annotation = 4, > + _is_shared_old_klass = 8 > }; > #endif I've added the bit and it will be set in `MetaspaceShared::linking_required`. Also replaced calling `MetaspaceShared::is_old_class()` with `k->is_shared_old_klass()` in several places. Thanks for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3479 From dholmes at openjdk.java.net Tue Apr 20 04:15:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 20 Apr 2021 04:15:05 GMT Subject: RFR: 8265017: runtime/HiddenClasses/StressHiddenClasses.java timed out on Win* OCI In-Reply-To: References: Message-ID: <75mQWKarvZB6XLbhhVHH4l8PJO2ibiGQRyTxwT4W4sU=.9eed63a4-b65d-4e6b-b1a8-d4486099af7d@github.com> On Mon, 19 Apr 2021 17:15:54 GMT, Harold Seigel wrote: > Please review this small test change to try to prevent test StressHiddenClasses,java from timing out. The change increases the test's timeout and prints some output the could be useful in future timeouts. > > The test was run over 1000 times on Windows with this change without any failures. > > Thanks, Harold Hi Harold, Your change to add the timeout seems fine and trivial. But ... I don't understand what this test is trying to do. With PARSE_TIMEOUT set to zero this test doesn't stress anything it just spawns 40000 threads sequentially and has the new thread define a hidden class, which AFAICS the main thread could do directly. ??? Cheers, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3574 From dholmes at openjdk.java.net Tue Apr 20 04:49:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 20 Apr 2021 04:49:05 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v2] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 21:39:18 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small fix. Method check_safepoint_and_suspend_for_native_trans() can just be removed and the code moved directly to check_special_condition_for_native_trans(). The other caller, transition_from_native(), can also just call SafepointMechanism::process_if_requested_with_exit_check() after transitioning to _thread_in_native_trans. Since that removes the only caller of is_suspend_after_native() I also removed it. >> I also made a small fix to has_special_runtime_exit_condition(). The compilers were generating three different comparisons for _suspend_flags instead of combining the constant values and doing a single one (I checked this with gcc 10.2 on linux and clang-12 on macos). The extra code was preventing inlining on some cases. For instance, on a Linux release build with gcc 10.2, for the ThreadInVMfromNative constructor, transition_from_native() was being inlined but not process_if_requested_with_exit_check(), so we still required a call for the fast case. The small change to has_special_runtime_exit_condition() fixed that. >> Tested in mach5 tiers1-2. >> >> Thanks, >> >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > fix typo in comment for check_special_condition_for_native_trans Hi Patricio, Given `check_safepoint_and_suspend_for_native_trans` is a simple wrapper around `SafepointMechanism::process_if_requested_with_exit_check`, this "inlining" seems reasonable. I have a couple of minor comments/suggestions below but nothing blocking. Note that thread.cpp line 649 still refers to the now deleted method. Thanks, David src/hotspot/share/runtime/interfaceSupport.inline.hpp line 122: > 120: // to the runtime from native code because the runtime is not set > 121: // up to handle exceptions floating around at arbitrary points. > 122: SafepointMechanism::process_if_requested_with_exit_check(thread, false /* check asyncs */); So previously we would check to see if there was a handshake/safepoint pending, or a suspend request, and if so process it. Now we batch the checks and processing together and actually check for additional conditions ie. deopt_suspend (which I'm guessing can't be set when returning from native?). So functionally this seems okay, but from a performance perspective there would seem to be a little more overhead in the case where there is nothing to do. An existing nit with process_if_requested_with_exit_check - the "exit check" pertains to calling handle_special_runtime_exit_condition, but here we are entering the runtime, not exiting it. I think the usage and naming of some of these methods is diverging. Possible future cleanup RFE. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3548 From dholmes at openjdk.java.net Tue Apr 20 04:49:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 20 Apr 2021 04:49:06 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v2] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:41:50 GMT, Daniel D. Daugherty wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo in comment for check_special_condition_for_native_trans > > src/hotspot/share/runtime/thread.hpp line 1325: > >> 1323: // under SR_lock in java_suspend_self(). >> 1324: return (_special_runtime_exit_condition != _no_async_condition) || >> 1325: (_suspend_flags & (_external_suspend | _obj_deopt JFR_ONLY(| _trace_flag))) != 0; > > I don't see this change mentioned in the bug report and it's > not obvious why you're changing this code. Also, I think this > is going to conflict with @robehn fix for JDK-8257831. Unless there is some significant performance issue with the lack of inlining I'd prefer to maintain code readability. And with Robbin's change is the inlining simplified anyway? Otherwise perhaps we should (re-)introduce is_any_suspend() to encapsulate the _suspend_flag checking? ------------- PR: https://git.openjdk.java.net/jdk/pull/3548 From stuefe at openjdk.java.net Tue Apr 20 06:03:07 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 20 Apr 2021 06:03:07 GMT Subject: RFR: JDK-8261238: NMT should not limit baselining by size threshold [v5] In-Reply-To: <4MIqmF_TbTMVhWnHSG5SegtWtUUd73ARTp5bVzKPLVY=.d2a0ebfe-a536-47a6-87ff-0e8509a16279@github.com> References: <-lC9Ton50BkMMCrq3L21QVM6ywOgRrQl5sHXDKMzWpI=.99ec02eb-8695-4422-8152-0b1473a14e8c@github.com> <4MIqmF_TbTMVhWnHSG5SegtWtUUd73ARTp5bVzKPLVY=.d2a0ebfe-a536-47a6-87ff-0e8509a16279@github.com> Message-ID: On Mon, 19 Apr 2021 16:00:32 GMT, Gerard Ziemski wrote: > Would it be easier for everyone to accept this change if you introduced a runtime flag to control the threshold size, and left it at 1K by default to match the current behavior? > > This way the default behavior does not change, but those who care can tweak it at runtime all the way to 0 to get the use case they want. Not sure. I think the problem may be that no-one beside @zhengyu123 and me knows the code base. @zhengyu123 what do you think, would you be more amenable toward this patch if it were guarded by an optional "-XX:+PreciseNMTButMoreMemory" switch? (Naming is facetious of course :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/2428 From rehn at openjdk.java.net Tue Apr 20 06:48:50 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Apr 2021 06:48:50 GMT Subject: RFR: 8257831: Suspend with handshakes [v12] In-Reply-To: <8SeoJUmAJV8_tx52dlAhwTVnlCYMrzqrT7yswrP07Fs=.908b8d5d-e60b-4c7d-8464-5c0c53a0cf3f@github.com> References: <8SeoJUmAJV8_tx52dlAhwTVnlCYMrzqrT7yswrP07Fs=.908b8d5d-e60b-4c7d-8464-5c0c53a0cf3f@github.com> Message-ID: <37QVdM3ZPotAqRfKd2LYzGq9mb2kj__txXi2hBuvynA=.f1f55dbd-267a-4b15-b08f-5886653607b6@github.com> On Mon, 19 Apr 2021 08:22:35 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into SuspendInHandshake > - Fixed DavidH second review > - Fixed nits > - Merge branch 'master' into SuspendInHandshake > - Review fixes 4 > - Fixed flag undef dep + spelling error > - Obsolete unused flags > - Review fixes 3 > - Merge branch 'master' into SuspendInHandshake > - Review fixes 2 > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/e390e550...2c652f94 Thanks for all input, done done !? :) Re-running test. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 20 06:48:47 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Apr 2021 06:48:47 GMT Subject: RFR: 8257831: Suspend with handshakes [v13] In-Reply-To: References: Message-ID: > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... Robbin Ehn 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 SuspendInHandshake - Removed double tty lock unlocks - Fixed comment from Dan and fixed name of handshake - Merge branch 'master' into SuspendInHandshake - Fixed DavidH second review - Fixed nits - Merge branch 'master' into SuspendInHandshake - Review fixes 4 - Fixed flag undef dep + spelling error - Obsolete unused flags - ... and 9 more: https://git.openjdk.java.net/jdk/compare/f1d4ae6c...56dc3df0 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=12 Stats: 1349 lines in 40 files changed: 271 ins; 882 del; 196 mod Patch: https://git.openjdk.java.net/jdk/pull/3191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191 PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Tue Apr 20 06:48:51 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Apr 2021 06:48:51 GMT Subject: RFR: 8257831: Suspend with handshakes [v2] In-Reply-To: References: Message-ID: <0zxUFM8s5JR-XKxLezw1Rht7-J15iIb2VqNIsv2OQBU=.abdf6bd4-6c6c-43fe-8155-92d908f76240@github.com> On Mon, 19 Apr 2021 18:19:05 GMT, Patricio Chilano Mateo wrote: >> Is this worth a comment above the `break_tty_lock_for_safepoint()` call? > > I also thought we could remove this since we are already releasing it in the ThreadInVMForHandshake constructor above. Yes, sorry, removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From aph at openjdk.java.net Tue Apr 20 08:13:17 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 20 Apr 2021 08:13:17 GMT Subject: Integrated: 8261445: Use memory_order_relaxed for os::random(). In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 14:49:12 GMT, Andrew Haley wrote: > os::random() is used a lot (once for every class) during HotSpot initialization, and it defaults to using a compare-and-swap operation with memory_order_conservative. We don't need that: it should be memory_order_relaxed. This pull request has now been integrated. Changeset: a25bae82 Author: Andrew Haley URL: https://git.openjdk.java.net/jdk/commit/a25bae82 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8261445: Use memory_order_relaxed for os::random(). Reviewed-by: adinn, eosterlund, mdoerr, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/2484 From stuefe at openjdk.java.net Tue Apr 20 11:26:05 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 20 Apr 2021 11:26:05 GMT Subject: RFR: 8264983: Add gtest for JDK-8264008 In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 12:34:00 GMT, Jie Fu wrote: > Hi all, > > Here is the gtest for JDK-8264008 as discussed here: https://github.com/openjdk/jdk/pull/3142#pullrequestreview-618244082 . > Any comments? > > Testing: > - test/hotspot/jtreg/gtest/MetaspaceUtilsGtests.java on Linux/{x64,x86_32} and macOSX > > Thanks. > Best regards, > Jie Looks good. Sorry for the long delay. ..Thomas test/hotspot/gtest/metaspace/test_metaspaceUtils.cpp line 76: > 74: } > 75: > 76: TEST_VM(MetaspaceUtils, none_compressed_class_pointers) { "non_compressed" ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3414 From jiefu at openjdk.java.net Tue Apr 20 11:37:23 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 20 Apr 2021 11:37:23 GMT Subject: RFR: 8264983: Add gtest for JDK-8264008 [v2] In-Reply-To: References: Message-ID: > Hi all, > > Here is the gtest for JDK-8264008 as discussed here: https://github.com/openjdk/jdk/pull/3142#pullrequestreview-618244082 . > Any comments? > > Testing: > - test/hotspot/jtreg/gtest/MetaspaceUtilsGtests.java on Linux/{x64,x86_32} and macOSX > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: none_compressed_class_pointers -> non_compressed_class_pointers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3414/files - new: https://git.openjdk.java.net/jdk/pull/3414/files/314664a7..9c5f0e9b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3414&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3414&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3414.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3414/head:pull/3414 PR: https://git.openjdk.java.net/jdk/pull/3414 From jiefu at openjdk.java.net Tue Apr 20 11:37:23 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 20 Apr 2021 11:37:23 GMT Subject: RFR: 8264983: Add gtest for JDK-8264008 [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 11:23:28 GMT, Thomas Stuefe wrote: > Looks good. Sorry for the long delay. > > ..Thomas Thanks @tstuefe for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3414 From dcubed at openjdk.java.net Tue Apr 20 15:49:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 20 Apr 2021 15:49:31 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating Message-ID: I'm updating the runtime/Thread/SuspendAtExit.java test: - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread() - switch from java.lang.Thread.resume() to JVM/TI ResumeThread() - switch from counter-based to time-based testing - improve error checking since we're now using an API with error codes! I've used this test to stress @robehn's fix for JDK-8257831 using both invocation styles for 9 hours each in {fastdebug, release, slowdebug} configs without any issues. I've run the updated test thru Mach5 Tier[134567] testing; one timeout was observed in a single Tier6 run on Win-X64. I believe this is a case of a lost Thread.interrupt() call. ------------- Commit messages: - 8265240: runtime/Thread/SuspendAtExit.java needs updating Changes: https://git.openjdk.java.net/jdk/pull/3576/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3576&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265240 Stats: 213 lines in 2 files changed: 165 ins; 21 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/3576.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3576/head:pull/3576 PR: https://git.openjdk.java.net/jdk/pull/3576 From rehn at openjdk.java.net Tue Apr 20 15:49:31 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 20 Apr 2021 15:49:31 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:15:18 GMT, Daniel D. Daugherty wrote: > I'm updating the runtime/Thread/SuspendAtExit.java test: > > - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread() > - switch from java.lang.Thread.resume() to JVM/TI ResumeThread() > - switch from counter-based to time-based testing > - improve error checking since we're now using an API with error codes! > > I've used this test to stress @robehn's fix for JDK-8257831 using both > invocation styles for 9 hours each in {fastdebug, release, slowdebug} > configs without any issues. > > I've run the updated test thru Mach5 Tier[134567] testing; one timeout > was observed in a single Tier6 run on Win-X64. I believe this is a case of > a lost Thread.interrupt() call. Thanks for fixing. Oh only in draft state ;) ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3576 From dcubed at openjdk.java.net Tue Apr 20 15:49:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 20 Apr 2021 15:49:31 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:15:18 GMT, Daniel D. Daugherty wrote: > I'm updating the runtime/Thread/SuspendAtExit.java test: > > - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread() > - switch from java.lang.Thread.resume() to JVM/TI ResumeThread() > - switch from counter-based to time-based testing > - improve error checking since we're now using an API with error codes! > > I've used this test to stress @robehn's fix for JDK-8257831 using both > invocation styles for 9 hours each in {fastdebug, release, slowdebug} > configs without any issues. > > I've run the updated test thru Mach5 Tier[134567] testing; one timeout > was observed in a single Tier6 run on Win-X64. I believe this is a case of > a lost Thread.interrupt() call. Oops. Forgot to mark it ready for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3576 From rrich at openjdk.java.net Tue Apr 20 16:05:05 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 20 Apr 2021 16:05:05 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v2] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 21:39:18 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small fix. Method check_safepoint_and_suspend_for_native_trans() can just be removed and the code moved directly to check_special_condition_for_native_trans(). The other caller, transition_from_native(), can also just call SafepointMechanism::process_if_requested_with_exit_check() after transitioning to _thread_in_native_trans. Since that removes the only caller of is_suspend_after_native() I also removed it. >> I also made a small fix to has_special_runtime_exit_condition(). The compilers were generating three different comparisons for _suspend_flags instead of combining the constant values and doing a single one (I checked this with gcc 10.2 on linux and clang-12 on macos). The extra code was preventing inlining on some cases. For instance, on a Linux release build with gcc 10.2, for the ThreadInVMfromNative constructor, transition_from_native() was being inlined but not process_if_requested_with_exit_check(), so we still required a call for the fast case. The small change to has_special_runtime_exit_condition() fixed that. >> Tested in mach5 tiers1-2. >> >> Thanks, >> >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > fix typo in comment for check_special_condition_for_native_trans The change looks good to me. Thanks, Richard. ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3548 From rrich at openjdk.java.net Tue Apr 20 16:05:05 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 20 Apr 2021 16:05:05 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 04:26:18 GMT, David Holmes wrote: >> src/hotspot/share/runtime/thread.hpp line 1325: >> >>> 1323: // under SR_lock in java_suspend_self(). >>> 1324: return (_special_runtime_exit_condition != _no_async_condition) || >>> 1325: (_suspend_flags & (_external_suspend | _obj_deopt JFR_ONLY(| _trace_flag))) != 0; >> >> I don't see this change mentioned in the bug report and it's >> not obvious why you're changing this code. Also, I think this >> is going to conflict with @robehn fix for JDK-8257831. > > Unless there is some significant performance issue with the lack of inlining I'd prefer to maintain code readability. And with Robbin's change is the inlining simplified anyway? Otherwise perhaps we should (re-)introduce is_any_suspend() to encapsulate the _suspend_flag checking? IMHO it is straight forward to check for multiple bits using a mask. I like that this improves fast paths e.g. of JNI calls. ------------- PR: https://git.openjdk.java.net/jdk/pull/3548 From patricio.chilano.mateo at oracle.com Tue Apr 20 17:00:19 2021 From: patricio.chilano.mateo at oracle.com (patricio.chilano.mateo at oracle.com) Date: Tue, 20 Apr 2021 14:00:19 -0300 Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v2] In-Reply-To: References: Message-ID: Hi David, Thanks for looking at this. On 4/20/21 1:49 AM, David Holmes wrote: > On Mon, 19 Apr 2021 21:39:18 GMT, Patricio Chilano Mateo wrote: > Hi Patricio, > > Given `check_safepoint_and_suspend_for_native_trans` is a simple wrapper around `SafepointMechanism::process_if_requested_with_exit_check`, this "inlining" seems reasonable. > > I have a couple of minor comments/suggestions below but nothing blocking. > > Note that thread.cpp line 649 still refers to the now deleted method. Yes, with Robbin's change that method will be gone so I'll wait for him to push first. > Thanks, > David > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 122: > >> 120: // to the runtime from native code because the runtime is not set >> 121: // up to handle exceptions floating around at arbitrary points. >> 122: SafepointMechanism::process_if_requested_with_exit_check(thread, false /* check asyncs */); > So previously we would check to see if there was a handshake/safepoint pending, or a suspend request, and if so process it. Now we batch the checks and processing together and actually check for additional conditions ie. deopt_suspend (which I'm guessing can't be set when returning from native?). So functionally this seems okay, but from a performance perspective there would seem to be a little more overhead in the case where there is nothing to do. Today we are also checking for _obj_deopt since that could be set when coming back from native. The only extra check that will be done when using process_if_requested_with_exit_check() instead of 'SafepointMechanism::should_process(thread) || thread->is_suspend_after_native()' is for async exceptions. (Note that today we are actually doing an extra check when calling SafepointMechanism::should_process() instead of just calling SafepointMechanism::local_poll_armed() as process_if_requested_with_exit_check() does, but that's a different issue and I filed 8265453 to fix that). If doing that extra check for async exceptions is a problem, instead of restoring the check 'SafepointMechanism::should_process(thread) || thread->is_suspend_after_native()' I think a better thing to do would be to just have the boolean 'check_asyncs' in has_special_runtime_exit_condition() instead of handle_special_runtime_exit_condition(), since it makes sense to filter that already in the check rather than afterwards in the slow path when processing. That boolean is always known at compile time so the check for async exceptions will be removed for these cases. That will also fix all other places were we check for all conditions but then call handle_special_runtime_exit_condition() and filter async exceptions. > An existing nit with process_if_requested_with_exit_check - the "exit check" pertains to calling handle_special_runtime_exit_condition, but here we are entering the runtime, not exiting it. I think the usage and naming of some of these methods is diverging. Possible future cleanup RFE. Yes, maybe process_if_requested_with_special_condition_check()? The names are starting to get long. : )? I can do it in a different RFE then. Thanks! Patricio > ------------- > > Marked as reviewed by dholmes (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3548 From pchilanomate at openjdk.java.net Tue Apr 20 17:06:03 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 20 Apr 2021 17:06:03 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v2] In-Reply-To: References: Message-ID: <89y9fUsLZwwNR_6MTvHtVWMNMB1yBIMuAnwEdBk019c=.e555f8bb-403d-4f39-aa77-204b38a27c88@github.com> On Tue, 20 Apr 2021 16:01:47 GMT, Richard Reingruber wrote: > The change looks good to me. > > Thanks, Richard. Thanks Richard! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3548 From pchilanomate at openjdk.java.net Tue Apr 20 17:06:04 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 20 Apr 2021 17:06:04 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 16:01:07 GMT, Richard Reingruber wrote: >> Unless there is some significant performance issue with the lack of inlining I'd prefer to maintain code readability. And with Robbin's change is the inlining simplified anyway? Otherwise perhaps we should (re-)introduce is_any_suspend() to encapsulate the _suspend_flag checking? > > IMHO it is straight forward to check for multiple bits using a mask. > I like that this improves fast paths e.g. of JNI calls. With Robbin's change is_external_suspend() will be gone since that check would be already embedded in the poll check. But because _suspend_flags is declared volatile the compilers will still generate two different checks for is_trace_suspend() || is_obj_deopt_suspend() instead of doing just one (checked that with gcc 10.2 and clang 12; without volatile only one check is made). After Robbin's change that line would become (_suspend_flags & (_obj_deopt JFR_ONLY(| _trace_flag))) != 0. I also would prefer this instead of having to jump to a different method but I don't mind encapsulating them. ------------- PR: https://git.openjdk.java.net/jdk/pull/3548 From hseigel at openjdk.java.net Tue Apr 20 17:51:30 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 20 Apr 2021 17:51:30 GMT Subject: RFR: 8263421: Module image file is opened twice during VM startup Message-ID: Please review this fix for JDK-8263421. The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file. The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file. This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once. The fix also removes some unused code related to module image file processing. The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3- 5 on Linux x64. Thanks, Harold ------------- Commit messages: - 8263421: Module image file is opened twice during VM startup Changes: https://git.openjdk.java.net/jdk/pull/3591/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3591&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263421 Stats: 61 lines in 2 files changed: 17 ins; 21 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/3591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3591/head:pull/3591 PR: https://git.openjdk.java.net/jdk/pull/3591 From pchilanomate at openjdk.java.net Tue Apr 20 18:12:31 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 20 Apr 2021 18:12:31 GMT Subject: RFR: 8257831: Suspend with handshakes [v13] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 06:48:47 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn 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 SuspendInHandshake > - Removed double tty lock unlocks > - Fixed comment from Dan and fixed name of handshake > - Merge branch 'master' into SuspendInHandshake > - Fixed DavidH second review > - Fixed nits > - Merge branch 'master' into SuspendInHandshake > - Review fixes 4 > - Fixed flag undef dep + spelling error > - Obsolete unused flags > - ... and 9 more: https://git.openjdk.java.net/jdk/compare/f1d4ae6c...56dc3df0 Latest version LGTM! Thanks, Patricio ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/3191 From iklam at openjdk.java.net Tue Apr 20 20:07:16 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 20 Apr 2021 20:07:16 GMT Subject: RFR: 8263421: Module image file is opened twice during VM startup In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 17:44:44 GMT, Harold Seigel wrote: > Please review this fix for JDK-8263421. The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file. The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file. > > This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once. > > The fix also removes some unused code related to module image file processing. > > The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3- > 5 on Linux x64. > > Thanks, Harold Looks good overall, but I think we should add some asserts to ensure safety. src/hotspot/share/classfile/classLoader.cpp line 393: > 391: ClassFileStream* ClassPathImageEntry::open_stream_for_loader(Thread* current, const char* name, ClassLoaderData* loader_data) { > 392: jlong size; > 393: JImageLocationRef location = (*JImageFindResource)(jimage(), "", get_jimage_version_string(), name, &size); There's a subtle change: * before: `_jimage` could never be NULL, since it's a private member of this `ClassPathImageEntry` * after: `jimage()` could theoretically be NULL, if `ClassPathImageEntry::close_jimage()` is called, which happens only when: * `~ClassPathImageEntry()` is called. But this will never happen because we never delete `ClassPathImageEntry`; * `ClassLoader::close_jrt_image()` is called. This happens only on Linux inside `os::abort()` When we call `jimage()` and expect it to be non-null, maybe we should use a new function `jimage_non_null()` like this: JImageFile* ClassPathImageEntry::jimage_non_null() { assert(ClassLoader::has_jrt_entry(), "must be"); assert(jimage() != NULL, "should have been opened by ClassLoader::lookup_vm_options " "and remained throughout normal JVM lifetime"); return jimage(); } and we should change `~ClassPathImageEntry()` to assert that it's never called? ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3591 From cjplummer at openjdk.java.net Tue Apr 20 21:54:13 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 20 Apr 2021 21:54:13 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v20] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 12:35:27 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - remove parallel option and dumpheapext command > - Revert "hide the dumpheapext error message" > > This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. > - resize large object threshold > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - code clean > - fix trailing white space issue > - ... and 15 more: https://git.openjdk.java.net/jdk/compare/e2106d5a...997784b1 > Hi Chris, > I am going to close the CSR https://bugs.openjdk.java.net/browse/JDK-8260424. > But it seems this PR also revised the `parallel` option's help message for `jmap -histo`, Do you think it is ok to keep the change in the PR? > > FYI, here is the commits [6789ba2](https://github.com/openjdk/jdk/commit/6789ba291a97a01fdc70258fb25dbf0d6464dba8) > > Thanks, > Lin I think it would be best to create a separate PR for that change. No CSR is needed for it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From dholmes at openjdk.java.net Tue Apr 20 22:04:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 20 Apr 2021 22:04:35 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v2] In-Reply-To: References: Message-ID: > If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. > > In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. > > This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. > > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Additional comments on failure modes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3580/files - new: https://git.openjdk.java.net/jdk/pull/3580/files/5681dfe4..264fbea5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3580&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3580&range=00-01 Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3580.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3580/head:pull/3580 PR: https://git.openjdk.java.net/jdk/pull/3580 From jiefu at openjdk.java.net Tue Apr 20 22:53:08 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 20 Apr 2021 22:53:08 GMT Subject: Integrated: 8264983: Add gtest for JDK-8264008 In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 12:34:00 GMT, Jie Fu wrote: > Hi all, > > Here is the gtest for JDK-8264008 as discussed here: https://github.com/openjdk/jdk/pull/3142#pullrequestreview-618244082 . > Any comments? > > Testing: > - test/hotspot/jtreg/gtest/MetaspaceUtilsGtests.java on Linux/{x64,x86_32} and macOSX > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: a22ad03b Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/a22ad03b Stats: 55 lines in 2 files changed: 55 ins; 0 del; 0 mod 8264983: Add gtest for JDK-8264008 Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/3414 From iklam at openjdk.java.net Wed Apr 21 01:54:07 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 01:54:07 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes wrote: >> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. >> >> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. >> >> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Additional comments on failure modes LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3580 From cjplummer at openjdk.java.net Wed Apr 21 02:01:17 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 21 Apr 2021 02:01:17 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v20] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 12:35:27 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - remove parallel option and dumpheapext command > - Revert "hide the dumpheapext error message" > > This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. > - resize large object threshold > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - code clean > - fix trailing white space issue > - ... and 15 more: https://git.openjdk.java.net/jdk/compare/e2106d5a...997784b1 Ok made a closer pass this time. Overall looks good except for some suggested edits, but I couldn't review all of it in detail. What type of testing are you doing? src/hotspot/share/services/attachListener.cpp line 252: > 250: // parallel thread number for heap dump, initialize based on active processor count. > 251: // Note the real number of threads used is also determined by active workers and compression > 252: // backend thread number, see heapDumper.cpp. The commas should really be periods to start new sentences. src/hotspot/share/services/heapDumper.cpp line 579: > 577: // this is already the correct length, since we don't add more sub-records. > 578: write_u4(len); > 579: assert (Bytes::get_Java_u4((address)(buffer() + 5)) == len, "Inconsitent size!"); Remove space. src/hotspot/share/services/heapDumper.cpp line 701: > 699: size_t _internal_buffer_used; > 700: char* _buffer_base; > 701: bool _splited_data; `_split_data`. Split is one of those english verbs that doesn't follow the rules. "I split the log yesterday" is correct, not "splited". src/hotspot/share/services/heapDumper.cpp line 721: > 719: > 720: public: > 721: ParDumpWriter(DumpWriter* dw) : The DumpWriter constructor has the following comment, which you should add here also: `// Check for error after constructing the object and destroy it in case of an error.` src/hotspot/share/services/heapDumper.cpp line 737: > 735: if (_buffer_base != NULL) { > 736: os::free(_buffer_base); > 737: _buffer_base = NULL; remove extra indentation space src/hotspot/share/services/heapDumper.cpp line 853: > 851: > 852: void flush_to_backend(bool force) { > 853: // Guarantee there is only one writer update backend buffers. "updating the backend buffers"? src/hotspot/share/services/heapDumper.cpp line 862: > 860: entry = NULL; > 861: } > 862: assert(_pos == 0, "available buffer must be clean before flush"); "empty" instead of "clean"? src/hotspot/share/services/heapDumper.cpp line 1665: > 1663: // To avoid memory consumption, when dumping large objects such as huge array and > 1664: // large objects whose size are larger than LARGE_OBJECT_DUMP_THRESHOLD, the scanned > 1665: // partial object/array data will be send to the backend directly instead of caching "sent" src/hotspot/share/services/heapDumper.cpp line 1668: > 1666: // the whole object/array in the internal buffer. > 1667: // The HeapDumpLargeObjectList is used to save the large object when dumper scans > 1668: // the heap. The large objects could be added (push) parallelly by multiple dumpers. "dumpers," src/hotspot/share/services/heapDumper.cpp line 1669: > 1667: // The HeapDumpLargeObjectList is used to save the large object when dumper scans > 1668: // the heap. The large objects could be added (push) parallelly by multiple dumpers. > 1669: // But they will be removed (pop) serially only by the VM thread. "popped" src/hotspot/share/services/heapDumper.cpp line 1690: > 1688: HeapDumpLargeObjectListElem* entry = new HeapDumpLargeObjectListElem(obj); > 1689: if (entry == NULL) { > 1690: warning("Fail to allocate element for large object list"); "failed" src/hotspot/share/services/heapDumper.cpp line 1774: > 1772: } > 1773: > 1774: // If large object list exist and it is large object/array, "exists" src/hotspot/share/services/heapDumper.cpp line 1775: > 1773: > 1774: // If large object list exist and it is large object/array, > 1775: // add oop into the list and skip scan, VM thread will process it later. "...scan. VM thread..." src/hotspot/share/services/heapDumper.cpp line 1842: > 1840: ml.wait(); > 1841: } > 1842: assert(_started == true, "dumper is waken up with wrong state"); "dumper work up" src/hotspot/share/services/heapDumper.cpp line 1918: > 1916: // Calculate dumper and writer threads number. > 1917: _num_writer_threads = num_total - _num_dumper_threads; > 1918: // If dumper threads number is zero, there is only VMThread work as a dumper. "If dumper threads number is zero, only the VMThread works as a dumper." src/hotspot/share/services/heapDumper.cpp line 1919: > 1917: _num_writer_threads = num_total - _num_dumper_threads; > 1918: // If dumper threads number is zero, there is only VMThread work as a dumper. > 1919: // If dumper threads number is equal to active workers, need at lest one thread work as writer. "...at least one worker thread..."? src/hotspot/share/services/heapDumperCompression.cpp line 240: > 238: } > 239: > 240: void CompressionBackend::flush_buffer() { This method looks to be indentical to `CompressionBackend::deactivate()` except `CompressionBackend::deactivate()` does a couple more tasks at the end. Perhaps `CompressionBackend::deactivate()` should be calling this now. src/hotspot/share/services/heapDumperCompression.cpp line 404: > 402: assert(buffer != NULL && used != 0 && max != 0, "Invalid data send to compression backend"); > 403: assert(_active == true, "Backend must be active when flushing external buffer"); > 404: // force flush buffered data and get new buffer. This is an odd location for this comment. I think i should go before the method and also match the (modified) comment found in the .hpp file. src/hotspot/share/services/heapDumperCompression.cpp line 410: > 408: > 409: MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); > 410: // first try current work. if it is clean Do you mean "First try current work buffer. Use it if empty."? src/hotspot/share/services/heapDumperCompression.cpp line 417: > 415: get_new_buffer(&buf, &tmp_used, &tmp_max, true); > 416: } > 417: assert (_current != NULL && _current->_in != NULL && _current->_in_max >= max && `_current` can't possibly be NULL here since you referenced `_current->_in_used` a few lines above. src/hotspot/share/services/heapDumperCompression.hpp line 221: > 219: char const* error() const { return _err; } > 220: > 221: // sets up a internal buffer, fill with external buffer and send to compressor // Sets up a internal buffer, fills with external buffer, and sends to compressor. src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java line 232: > 230: if (compress_level.length() == 0) { > 231: System.err.println("Fail: no number provided in option: '" + subopt + "'"); > 232: usage(1); I think lines 231 and 232 have an extra indentation of 1 space. Since this change is unrelated to the CR being fixed, perhaps it would be best to do these changes with the new CR you are going to create for the help output changes below. ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From lzang at openjdk.java.net Wed Apr 21 02:28:13 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 21 Apr 2021 02:28:13 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v20] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 12:35:27 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - remove parallel option and dumpheapext command > - Revert "hide the dumpheapext error message" > > This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. > - resize large object threshold > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - code clean > - fix trailing white space issue > - ... and 15 more: https://git.openjdk.java.net/jdk/compare/e2106d5a...997784b1 Dear Chris, Thanks a lot for your help, I have created a new PR for the `jmap -histo:parallel=n` help message at https://github.com/openjdk/jdk/pull/3598. And I will revert it in this PR and also revise the patch based on your latest comments. The tests I have conducted are quite similar with what Ralf have done and suggested: > > ``` > jmap.exe -dump:file=ser.hprof,all 30600 > Dumping heap to ser.hprof ... > Heap dump file created [32009882362 bytes in 59.303 secs] > > jmap.exe -dump:file=par1.hprof,parallel=1,all 30600 > Dumping heap to par1.hprof ... > Heap dump file created [32009885809 bytes in 72.719 secs] > > jmap.exe -dump:file=par2.hprof,parallel=2,all 30600 > Dumping heap to par2.hprof ... > Heap dump file created [32009881876 bytes in 57.546 secs] > > jmap.exe -dump:file=par4.hprof,parallel=4,all 30600 > Dumping heap to par4.hprof ... > Heap dump file created [32009882956 bytes in 44.301 secs] > > jmap.exe -dump:file=par5.hprof,parallel=5,all 30600 > Dumping heap to par5.hprof ... > Heap dump file created [32009882164 bytes in 40.282 secs] > > jmap.exe -dump:file=par6.hprof,parallel=6,all 30600 > Dumping heap to par6.hprof ... > Heap dump file created [32009881156 bytes in 45.988 secs] > ``` > > And here for the compressed case: > > ``` > jmap.exe -dump:file=par1.hprof.gz,parallel=1,all,gz=1 52372 > Dumping heap to par1.hprof.gz ... > Heap dump file created [8076994216 bytes in 54.057 secs] > > jmap.exe -dump:file=par2.hprof.gz,parallel=2,all,gz=1 52372 > Dumping heap to par2.hprof.gz ... > Heap dump file created [8075859421 bytes in 43.442 secs] > > jmap.exe -dump:file=par4.hprof.gz,parallel=4,all,gz=1 52372 > Dumping heap to par4.hprof.gz ... > Heap dump file created [8075886152 bytes in 28.710 secs] > > jmap.exe -dump:file=par6.hprof.gz,parallel=6,all,gz=1 52372 > Dumping heap to par6.hprof.gz ... > Heap dump file created [8075758374 bytes in 25.730 secs] > > jmap.exe -dump:file=par8.hprof.gz,parallel=8,all,gz=1 52372 > Dumping heap to par8.hprof.gz ... > Heap dump file created [8075652558 bytes in 26.039 secs] > > jmap.exe -dump:file=par16.hprof.gz,parallel=16,all,gz=1 52372 > Dumping heap to par16.hprof.gz ... > Heap dump file created [8075644423 bytes in 31.977 secs] > > jmap.exe -dump:file=par24.hprof.gz,parallel=24,all,gz=1 52372 > Dumping heap to par24.hprof.gz ... > Heap dump file created [8075579546 bytes in 41.094 secs] > ``` And I will conduct it again since now there is no `parallel=` option. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From dlong at openjdk.java.net Wed Apr 21 03:23:04 2021 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 21 Apr 2021 03:23:04 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes wrote: >> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. >> >> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. >> >> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Additional comments on failure modes If this gets backported to an older jdk where CATCH called ShouldNotReachHere() instead of assert(), then it will be a change in behavior, right? What's the reason for moving the exception throwing into the caller? Is it necessary or just an optimization? ------------- PR: https://git.openjdk.java.net/jdk/pull/3580 From dholmes at openjdk.java.net Wed Apr 21 04:35:29 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Apr 2021 04:35:29 GMT Subject: RFR: 8257831: Suspend with handshakes [v13] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 06:48:47 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn 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 SuspendInHandshake > - Removed double tty lock unlocks > - Fixed comment from Dan and fixed name of handshake > - Merge branch 'master' into SuspendInHandshake > - Fixed DavidH second review > - Fixed nits > - Merge branch 'master' into SuspendInHandshake > - Review fixes 4 > - Fixed flag undef dep + spelling error > - Obsolete unused flags > - ... and 9 more: https://git.openjdk.java.net/jdk/compare/f1d4ae6c...56dc3df0 Looks good. src/hotspot/share/runtime/handshake.cpp line 633: > 631: void do_thread(Thread* thr) { > 632: JavaThread* current = thr->as_Java_thread(); > 633: assert(current == Thread::current(), "Must be self executed."); Possibly overkill given do_self_suspend() has a similar assertion. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dholmes at openjdk.java.net Wed Apr 21 04:39:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Apr 2021 04:39:23 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 07:13:57 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/handshake.hpp line 133: >> >>> 131: // check the _lock, if held go to slow path. >>> 132: // Since the handshakee is unsafe if _lock gets locked after this check >>> 133: // we know another thread cannot process any handshakes. >> >> I can't quite understand this comment. I'm not sure what thread is calling this method and when, in relation to what the handshakee may be doing. > > The handshakee is in a safe state, e.g. blocked and does: > Point A: set_thread_state_fence(_thread_blocked_trans); > ... > Point B: _lock.is_locked() > > While the processor thread does: > Point X: _lock.try_lock(); > ... > Point Z: thread->thread_state(); > > If point B is passed with a non-locked lock, point Z is guaranteed to see an unsafe thread and will not start to process ay handshakes. > > Is that make sense, maybe the comment make more sense ? :) The comment makes more sense now :) >> src/hotspot/share/runtime/handshake.hpp line 157: >> >>> 155: Thread* active_handshaker() const { return _active_handshaker; } >>> 156: >>> 157: // Suspend/resume support >> >> Taking a step back I can't help but think that this is entirely the wrong place to have the suspend/resume API and supporting code. It is only here because we re-use the HandshakeState _lock monitor right? If we introduced a new thread-suspension monitor instead then this code would all reside somewhere else - probably in the JavaThread class. > > When going to blocked inside the async handshake we **must** unlock the HandshakeState lock. > Thus _lock.wait() unlocks and gives us something to notify. > We could do: > > _lock.unlock(); > { > MutexLocker(SomeOtherLock) ml; > SomeOtherLock.wait(); > } > _lock.lock(); > > > Another alternative is to create a friend class which uses the HandshakeState lock and having the API there instead. Borrowing the HandshakeState lock does create an artificial coupling here. I'd prefer to see this API in a more natural place with friendship used to access the mechanism as needed. Future cleanup though. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dholmes at openjdk.java.net Wed Apr 21 04:42:27 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Apr 2021 04:42:27 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 04:36:07 GMT, David Holmes wrote: >> When going to blocked inside the async handshake we **must** unlock the HandshakeState lock. >> Thus _lock.wait() unlocks and gives us something to notify. >> We could do: >> >> _lock.unlock(); >> { >> MutexLocker(SomeOtherLock) ml; >> SomeOtherLock.wait(); >> } >> _lock.lock(); >> >> >> Another alternative is to create a friend class which uses the HandshakeState lock and having the API there instead. > > Borrowing the HandshakeState lock does create an artificial coupling here. I'd prefer to see this API in a more natural place with friendship used to access the mechanism as needed. Future cleanup though. Also I think you'd have a lost-wakeup problem if two locks were involved. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From cjplummer at openjdk.java.net Wed Apr 21 05:25:12 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 21 Apr 2021 05:25:12 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v20] In-Reply-To: References: Message-ID: <9Q69ICl9o5uaRsoDDEa43b9Vl21lzaZIHe2f8mvQy7c=.b1b36b58-787a-4950-9afe-31ca4c79165b@github.com> On Wed, 14 Apr 2021 12:35:27 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - remove parallel option and dumpheapext command > - Revert "hide the dumpheapext error message" > > This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. > - resize large object threshold > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - code clean > - fix trailing white space issue > - ... and 15 more: https://git.openjdk.java.net/jdk/compare/e2106d5a...997784b1 My concerns with your proposed testing is that it always targets the same application with the same heap, and does not read/process the hprof file to make sure it is not corrupt. ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From david.holmes at oracle.com Wed Apr 21 05:38:47 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Apr 2021 15:38:47 +1000 Subject: RFR: 8262953: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails if CPU quoata is not enabled In-Reply-To: References: <3dzz6fM8xBQqzoDATyd1gkPLOG5bZIbDHvxTKA9nshc=.0c56453e-0d7e-4cd4-a5a2-033e2e6f9d1c@github.com> Message-ID: On 19/04/2021 7:05 pm, Severin Gehwolf wrote: > On Thu, 25 Mar 2021 20:11:30 GMT, Anton Ostrouhhov wrote: > >> Hello! >> Both _CPU Quota_ and _CPU Period_ are missing from output if kernel was built without `CONFIG_CFS_BANDWIDTH`. >> >> This is my first contribution so please tell me if i am wrong somewhere. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ >> >> On 16/04/2021 10:26 pm, Severin Gehwolf wrote: >> >>> On Fri, 16 Apr 2021 12:18:05 GMT, David Holmes wrote: >>>> I'm not sure my, simple, point is getting through. Here's the cgroupv1 code: >>>> ``` >>>> /* cpu_quota >>>> * >>>> * Return the number of microseconds per period >>>> * process is guaranteed to run. >>>> * >>>> * return: >>>> * quota time in microseconds >>>> * -1 for no quota >>>> * OSCONTAINER_ERROR for not supported >>>> */ >>>> int CgroupV1Subsystem::cpu_quota() { >>>> GET_CONTAINER_INFO(int, _cpu->controller(), "/cpu.cfs_quota_us", >>>> "CPU Quota is: %d", "%d", quota); >>>> return quota; >>>> } >>>> ``` >>>> But if GET_CONTAINER_INFO doesn't find /cpu.cfs_quota_us the macro does "return OSCONTAINER_ERROR" which is "return -2". Yet the spec states that if there is no quota then -1 is returned, so why are we not returning -1? >>> >>> >>> @dholmes-ora Because they're not equivalent. `-1` means, the system supports it in general, but no cgroups quota is in place. I.e. unlimited. For example A) `docker run --memory 200M ` on a cgroup capable system with all the kernel support should report the memory limit. B) `docker run `. Case B) would return -1. `-2` is usually something unexpected and means the system doesn't support it (be it by kernel config, the file not being present where a file is expected to be present, etc.). We want to distinguish those two cases. >> >> I don't see why the user cares about this distinction. > > That's how it's presented to the user (no distinction). > > This mapping is being done in function `CgroupSubsystem::active_processor_count` here: > https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/cgroupSubsystem_linux.cpp#L442 > > I might have done a poor job at describing why we **internally** want to distinguish those two cases. Note that, we are discussing this in the context of a test failure. The test seems to assume that if cgroups is available (hotspot requires `memory`, `cpu`, `cpuset`, `cpuacct` and all seem present), the assumption is that `CONFIG_CFS_BANDWIDTH` is on too. > >> We might care for >> logging purposes but that is different. > > It's this exact issue, is it not? The test uses container trace logging to assert quotas are being recognized (even for the plain cgroup case). It doesn't account for the `CONFIG_CFS_BANDWIDTH=no` case apparently. Sorry I wasn't clear. The logging would distinguish the exact case not-supported versus not-set, but would still report something. David >> There is no difference to the >> end user between cgroups defines no quota and cgroups quotas are not >> compiled into the kernel. > > Agreed. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3206 > From lzang at openjdk.java.net Wed Apr 21 05:59:10 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 21 Apr 2021 05:59:10 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v20] In-Reply-To: <9Q69ICl9o5uaRsoDDEa43b9Vl21lzaZIHe2f8mvQy7c=.b1b36b58-787a-4950-9afe-31ca4c79165b@github.com> References: <9Q69ICl9o5uaRsoDDEa43b9Vl21lzaZIHe2f8mvQy7c=.b1b36b58-787a-4950-9afe-31ca4c79165b@github.com> Message-ID: On Wed, 21 Apr 2021 05:22:26 GMT, Chris Plummer wrote: > My concerns with your proposed testing is that it always targets the same application with the same heap, and does not read/process the hprof file to make sure it is not corrupt. Hmm, I agree, I will do more test and update here. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From dholmes at openjdk.java.net Wed Apr 21 06:07:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Apr 2021 06:07:06 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:15:18 GMT, Daniel D. Daugherty wrote: > I'm updating the runtime/Thread/SuspendAtExit.java test: > > - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread() > - switch from java.lang.Thread.resume() to JVM/TI ResumeThread() > - switch from counter-based to time-based testing > - improve error checking since we're now using an API with error codes! > > I've used this test to stress @robehn's fix for JDK-8257831 using both > invocation styles for 9 hours each in {fastdebug, release, slowdebug} > configs without any issues. > > I've run the updated test thru Mach5 Tier[134567] testing; one timeout > was observed in a single Tier6 run on Win-X64. I believe this is a case of > a lost Thread.interrupt() call. Hi Dan, A few nits (mostly pre-existing) but otherwise the conversion to JVMTI looks good. Thanks, David test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 90: > 88: while (System.currentTimeMillis() < start_time + (timeMax * 1000)) { > 89: count++; > 90: SuspendAtExit threads[] = new SuspendAtExit[N_THREADS]; Style nit pre-existing: The [] go on the type not the variable. test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 103: > 101: // the exitSyncObj.await() call and the SuspendThread() > 102: // calls will come in during thread exit. > 103: threads[i].interrupt(); Pre-existing: why use interrupt() instead of simply calling countDown() on the latch ?? test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 159: > 157: "after thread #" + i + > 158: " has been join()'ed"); > 159: } This is unnecessary, you aren't testing the correctness of Thread.join() here. join() can't return normally if the thread is alive. test/hotspot/jtreg/runtime/Thread/libSuspendAtExit.cpp line 2: > 1: /* > 2: * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights reserved. Copyright year should just be 2021. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3576 From dholmes at openjdk.java.net Wed Apr 21 06:11:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Apr 2021 06:11:18 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 17:02:11 GMT, Patricio Chilano Mateo wrote: >> IMHO it is straight forward to check for multiple bits using a mask. >> I like that this improves fast paths e.g. of JNI calls. > > With Robbin's change is_external_suspend() will be gone since that check would be already embedded in the poll check. But because _suspend_flags is declared volatile the compilers will still generate two different checks for is_trace_suspend() || is_obj_deopt_suspend() instead of doing just one (checked that with gcc 10.2 and clang 12; without volatile only one check is made). After Robbin's change that line would become (_suspend_flags & (_obj_deopt JFR_ONLY(| _trace_flag))) != 0. I also would prefer this instead of having to jump to a different method but I don't mind encapsulating them. I can live with it, but I highly doubt this has any observable affect on performance - especially taking into consideration the other code path changes that have been introduced in this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/3548 From david.holmes at oracle.com Wed Apr 21 06:19:20 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Apr 2021 16:19:20 +1000 Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v2] In-Reply-To: References: Message-ID: <7ef4daa8-f884-11ad-fe53-c5688f7ed162@oracle.com> Hi Dean, Thanks for looking at this. On 21/04/2021 1:23 pm, Dean Long wrote: > On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes wrote: > >>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. >>> >>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. >>> >>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. >>> >>> Testing: tiers 1-3 >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional comments on failure modes > > If this gets backported to an older jdk where CATCH called ShouldNotReachHere() instead of assert(), then it will be a change in behavior, right? Right - though there is really no direct reason to backport such cleanups. Also Ioi and I were discussing that perhaps we should revert the current version of CATCH so it once again aborts in the product VM, and then fix up call-sites like these. But these call-sites would ideally properly deal with exceptions in regular JavaThreads - somehow. > What's the reason for moving the exception throwing into the caller? Is it necessary or just an optimization? Necessary to get TRAPS out of the method signatures because I'm changing TRAPS to be JavaThread (in another issue) and compute_map is not always called on a JavaThread. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3580 > From david.holmes at oracle.com Wed Apr 21 06:19:44 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Apr 2021 16:19:44 +1000 Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v2] In-Reply-To: References: Message-ID: On 21/04/2021 11:54 am, Ioi Lam wrote: > On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes wrote: > >>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. >>> >>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. >>> >>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. >>> >>> Testing: tiers 1-3 >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional comments on failure modes > > LGTM. Thanks Ioi! David > ------------- > > Marked as reviewed by iklam (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3580 > From rehn at openjdk.java.net Wed Apr 21 07:32:28 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 21 Apr 2021 07:32:28 GMT Subject: RFR: 8257831: Suspend with handshakes [v10] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 04:39:35 GMT, David Holmes wrote: >> Borrowing the HandshakeState lock does create an artificial coupling here. I'd prefer to see this API in a more natural place with friendship used to access the mechanism as needed. Future cleanup though. > > Also I think you'd have a lost-wakeup problem if two locks were involved. You are correct, above those not work as is. We would need to protect the suspend flag with SomeOtherLock, thus also needing to lock SomeOtherLock when suspending. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 21 07:42:34 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 21 Apr 2021 07:42:34 GMT Subject: RFR: 8257831: Suspend with handshakes [v13] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 18:09:07 GMT, Patricio Chilano Mateo wrote: > Latest version LGTM! > > Thanks, > Patricio Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 21 07:42:34 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 21 Apr 2021 07:42:34 GMT Subject: RFR: 8257831: Suspend with handshakes [v13] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 04:32:36 GMT, David Holmes wrote: > Looks good. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 21 07:59:09 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 21 Apr 2021 07:59:09 GMT Subject: RFR: 8257831: Suspend with handshakes [v14] In-Reply-To: References: Message-ID: > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' into SuspendInHandshake - Merge branch 'master' into SuspendInHandshake - Removed double tty lock unlocks - Fixed comment from Dan and fixed name of handshake - Merge branch 'master' into SuspendInHandshake - Fixed DavidH second review - Fixed nits - Merge branch 'master' into SuspendInHandshake - Review fixes 4 - Fixed flag undef dep + spelling error - ... and 10 more: https://git.openjdk.java.net/jdk/compare/7146104f...ec344661 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3191&range=13 Stats: 1349 lines in 40 files changed: 271 ins; 882 del; 196 mod Patch: https://git.openjdk.java.net/jdk/pull/3191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3191/head:pull/3191 PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 21 09:18:14 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 21 Apr 2021 09:18:14 GMT Subject: RFR: 8257831: Suspend with handshakes [v14] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 07:59:09 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - Removed double tty lock unlocks > - Fixed comment from Dan and fixed name of handshake > - Merge branch 'master' into SuspendInHandshake > - Fixed DavidH second review > - Fixed nits > - Merge branch 'master' into SuspendInHandshake > - Review fixes 4 > - Fixed flag undef dep + spelling error > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/7146104f...ec344661 I'll push tomorrow morning and fill RFE to fix the manual transitions in OM/rawmonitor. Please object if there is some major that cannot be fixed as a follow-up. Thanks for all the feedback! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dlong at openjdk.java.net Wed Apr 21 09:40:49 2021 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 21 Apr 2021 09:40:49 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v2] In-Reply-To: References: Message-ID: <1vM-RogqXpz7izNhHR-toQyyNmqGq-VEYSrhVcjU5Fw=.f1597299-3ad8-4e84-b6f9-f2590f59dd1a@github.com> On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes wrote: >> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. >> >> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. >> >> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Additional comments on failure modes Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3580 From mdoerr at openjdk.java.net Wed Apr 21 10:12:47 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 21 Apr 2021 10:12:47 GMT Subject: RFR: JDK-8261238: NMT should not limit baselining by size threshold [v5] In-Reply-To: <-lC9Ton50BkMMCrq3L21QVM6ywOgRrQl5sHXDKMzWpI=.99ec02eb-8695-4422-8152-0b1473a14e8c@github.com> References: <-lC9Ton50BkMMCrq3L21QVM6ywOgRrQl5sHXDKMzWpI=.99ec02eb-8695-4422-8152-0b1473a14e8c@github.com> Message-ID: On Tue, 23 Feb 2021 07:14:04 GMT, Thomas Stuefe wrote: >> NMT is a very useful tool to detect memory leaks. Its easy to use, relatively cheap and requires almost zero setup. >> >> But it artificially limits output to call sites with >1K total memory consumption. That is not helpful, as it confuses the developer and obscures possible memory leaks. It also introduces subtle display errors in that callsites suddenly seem to appear, when comparing to the baseline, with a load of >1K when in fact they had been there already when the baseline was taken. >> >> I propose to remove the 1K limit completely. This will marginally increase the costs of taking "detail" NMT reports by about 210K for a single report, 420K for a report done using a baseline. >> >> If this is really a problem preventing us from getting more precise NMT output (really?) there are possibilities to decrease the cost again by sharing call stacks by reference instead of copying them around. I have a patch in work which does just that (https://bugs.openjdk.java.net/browse/JDK-8261491), but I honestly think adding 200-400K *temporarily* during NMT detail reporting would not be such a big deal. > > Thomas Stuefe 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 > - Split out display changes > - Exclude zero-sized regions from baseline > - Start I'm convinced that Thomas' version is better. Especially after his additional enhancement he has promised (JDK-8261491). NMT should be able to dectect memory leaks caused by small allocations. So using no threshold should be default IMHO. And I prefer not to add a switch. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2428 From shade at openjdk.java.net Wed Apr 21 10:28:34 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 10:28:34 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v2] In-Reply-To: References: Message-ID: On Sat, 10 Apr 2021 05:59:43 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Make jcheck happy: remove the TAB > - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels Anyone? This unfortunately breaks `tier1` on some of our testing hosts. ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From vlivanov at openjdk.java.net Wed Apr 21 10:44:04 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 21 Apr 2021 10:44:04 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 [v2] In-Reply-To: References: Message-ID: > `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. > > The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. > > Proposed fix is to start the search from the frame reported by `os::current_frame()`. > > Testing: > - [x] failing test > - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Improve the comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3554/files - new: https://git.openjdk.java.net/jdk/pull/3554/files/9f21b3bb..0d86a907 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3554&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3554&range=00-01 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3554.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3554/head:pull/3554 PR: https://git.openjdk.java.net/jdk/pull/3554 From vlivanov at openjdk.java.net Wed Apr 21 10:51:01 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 21 Apr 2021 10:51:01 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 [v3] In-Reply-To: References: Message-ID: <9kvrrZyldW2ygTauBsVGLz2wP1LbXZiWFWaexqcFugs=.1e40b02a-d215-476d-83d4-993552c6c10c@github.com> > `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. > > The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. > > Proposed fix is to start the search from the frame reported by `os::current_frame()`. > > Testing: > - [x] failing test > - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into 8265218.mh_logging - Improve the comment - Merge branch 'master' into 8265218.mh_logging - Remove from test/hotspot/jtreg/ProblemList-Xcomp.txt - 8265218: trace_method_handle_stub fails to find calling frame on x86 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3554/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3554&range=02 Stats: 12 lines in 2 files changed: 8 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3554.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3554/head:pull/3554 PR: https://git.openjdk.java.net/jdk/pull/3554 From vlivanov at openjdk.java.net Wed Apr 21 10:51:01 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 21 Apr 2021 10:51:01 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 [v3] In-Reply-To: References: <2_xzvM3b_0D2QgN9Ne6bMoHW2CigySF8_JE-L_Au0Ok=.b699d607-2431-419c-b427-4fac2699b1b4@github.com> <9063lFKlCv0VeB8ecsOGSEMOYF52_HSZjkxobaa1kRU=.c26fc2ed-f228-4b85-9f86-170addcaf63f@github.com> Message-ID: On Mon, 19 Apr 2021 22:07:39 GMT, Daniel D. Daugherty wrote: >> Why I thought that explicitly calling that it's the "caller's frame" makes things clearer: >> (1) the code explicitly is written in such a way to skip any intermediate frames; >> (2) all users are in generated code. >> >> So, we know for sure there's a separate frame on the stack (which contains register values) and it differs from the top one. The bug is that we can't skip the frame returned by `os::current_frame()` because it doesn't return the top frame on the stack, but the next one. > > Removing the comment doesn't help the reader understand the code. > Please replace the comment with something that accurately explains > what happens from this `os::current_frame()` call site. Done. Is it better now? ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From dholmes at openjdk.java.net Wed Apr 21 10:56:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Apr 2021 10:56:36 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v2] In-Reply-To: References: Message-ID: On Sat, 10 Apr 2021 05:59:43 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Make jcheck happy: remove the TAB > - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels Hi Aleksey, I can't really evaluate the changes as I'm not familiar with the information that is being queried. I get the gist of things and as this is a test the real question is whether the test now passes okay. So on that basis I'll approve it. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3415 From dholmes at openjdk.java.net Wed Apr 21 10:59:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Apr 2021 10:59:34 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 [v3] In-Reply-To: <9kvrrZyldW2ygTauBsVGLz2wP1LbXZiWFWaexqcFugs=.1e40b02a-d215-476d-83d4-993552c6c10c@github.com> References: <9kvrrZyldW2ygTauBsVGLz2wP1LbXZiWFWaexqcFugs=.1e40b02a-d215-476d-83d4-993552c6c10c@github.com> Message-ID: On Wed, 21 Apr 2021 10:51:01 GMT, Vladimir Ivanov wrote: >> `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. >> >> The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. >> >> Proposed fix is to start the search from the frame reported by `os::current_frame()`. >> >> Testing: >> - [x] failing test >> - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into 8265218.mh_logging > - Improve the comment > - Merge branch 'master' into 8265218.mh_logging > - Remove from test/hotspot/jtreg/ProblemList-Xcomp.txt > - 8265218: trace_method_handle_stub fails to find calling frame on x86 Updated comment is okay to me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3554 From redestad at openjdk.java.net Wed Apr 21 11:05:01 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 21 Apr 2021 11:05:01 GMT Subject: RFR: 8265607: Avoid decrementing when no Symbol was created in ~SignatureStream Message-ID: This patch trivially avoids decrementing refcount on java/lang/Object (a permanent symbol) that is used as a sentinel when the SignatureStream found no Symbols during parse. This is the common case, especially during early VM startup ------------- Commit messages: - missing semi - Skip refcount decrement if no Symbols were created during signature parse Changes: https://git.openjdk.java.net/jdk/pull/3596/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3596&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265607 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3596.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3596/head:pull/3596 PR: https://git.openjdk.java.net/jdk/pull/3596 From zgu at openjdk.java.net Wed Apr 21 11:41:44 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 21 Apr 2021 11:41:44 GMT Subject: RFR: JDK-8261238: NMT should not limit baselining by size threshold [v5] In-Reply-To: <-lC9Ton50BkMMCrq3L21QVM6ywOgRrQl5sHXDKMzWpI=.99ec02eb-8695-4422-8152-0b1473a14e8c@github.com> References: <-lC9Ton50BkMMCrq3L21QVM6ywOgRrQl5sHXDKMzWpI=.99ec02eb-8695-4422-8152-0b1473a14e8c@github.com> Message-ID: <-wvZOwr2zx2PSkvJzu_qH4wFNRnhL03qP4v5ubhPR_U=.7740e796-5cea-4013-991c-f789fc494ac9@github.com> On Tue, 23 Feb 2021 07:14:04 GMT, Thomas Stuefe wrote: >> NMT is a very useful tool to detect memory leaks. Its easy to use, relatively cheap and requires almost zero setup. >> >> But it artificially limits output to call sites with >1K total memory consumption. That is not helpful, as it confuses the developer and obscures possible memory leaks. It also introduces subtle display errors in that callsites suddenly seem to appear, when comparing to the baseline, with a load of >1K when in fact they had been there already when the baseline was taken. >> >> I propose to remove the 1K limit completely. This will marginally increase the costs of taking "detail" NMT reports by about 210K for a single report, 420K for a report done using a baseline. >> >> If this is really a problem preventing us from getting more precise NMT output (really?) there are possibilities to decrease the cost again by sharing call stacks by reference instead of copying them around. I have a patch in work which does just that (https://bugs.openjdk.java.net/browse/JDK-8261491), but I honestly think adding 200-400K *temporarily* during NMT detail reporting would not be such a big deal. > > Thomas Stuefe 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 > - Split out display changes > - Exclude zero-sized regions from baseline > - Start Marked as reviewed by zgu (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2428 From zgu at openjdk.java.net Wed Apr 21 11:41:44 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 21 Apr 2021 11:41:44 GMT Subject: RFR: JDK-8261238: NMT should not limit baselining by size threshold [v5] In-Reply-To: References: <-lC9Ton50BkMMCrq3L21QVM6ywOgRrQl5sHXDKMzWpI=.99ec02eb-8695-4422-8152-0b1473a14e8c@github.com> <4MIqmF_TbTMVhWnHSG5SegtWtUUd73ARTp5bVzKPLVY=.d2a0ebfe-a536-47a6-87ff-0e8509a16279@github.com> Message-ID: On Tue, 20 Apr 2021 05:59:54 GMT, Thomas Stuefe wrote: > > Would it be easier for everyone to accept this change if you introduced a runtime flag to control the threshold size, and left it at 1K by default to match the current behavior? > > This way the default behavior does not change, but those who care can tweak it at runtime all the way to 0 to get the use case they want. > > Not sure. I think the problem may be that no-one beside @zhengyu123 and me knows the code base. > > @zhengyu123 what do you think, would you be more amenable toward this patch if it were guarded by an optional "-XX:+PreciseNMTButMoreMemory" switch? (Naming is facetious of course :-) Seems no one raised concerns on memory consumption, I am good. ------------- PR: https://git.openjdk.java.net/jdk/pull/2428 From stuefe at openjdk.java.net Wed Apr 21 11:50:40 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 11:50:40 GMT Subject: RFR: JDK-8261238: NMT should not limit baselining by size threshold [v5] In-Reply-To: References: <-lC9Ton50BkMMCrq3L21QVM6ywOgRrQl5sHXDKMzWpI=.99ec02eb-8695-4422-8152-0b1473a14e8c@github.com> Message-ID: On Wed, 21 Apr 2021 10:09:35 GMT, Martin Doerr wrote: >> Thomas Stuefe 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 >> - Split out display changes >> - Exclude zero-sized regions from baseline >> - Start > > I'm convinced that Thomas' version is better. Especially after his additional enhancement he has promised (JDK-8261491). > NMT should be able to dectect memory leaks caused by small allocations. So using no threshold should be default IMHO. And I prefer not to add a switch. Thanks @TheRealMDoerr and @zhengyu123 ! I'll wait until tomorrow. If nobody objects, I will merge this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2428 From stuefe at openjdk.java.net Wed Apr 21 12:06:05 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 12:06:05 GMT Subject: RFR: JDK-8261238: NMT should not limit baselining by size threshold [v6] In-Reply-To: References: Message-ID: > NMT is a very useful tool to detect memory leaks. Its easy to use, relatively cheap and requires almost zero setup. > > But it artificially limits output to call sites with >1K total memory consumption. That is not helpful, as it confuses the developer and obscures possible memory leaks. It also introduces subtle display errors in that callsites suddenly seem to appear, when comparing to the baseline, with a load of >1K when in fact they had been there already when the baseline was taken. > > I propose to remove the 1K limit completely. This will marginally increase the costs of taking "detail" NMT reports by about 210K for a single report, 420K for a report done using a baseline. > > If this is really a problem preventing us from getting more precise NMT output (really?) there are possibilities to decrease the cost again by sharing call stacks by reference instead of copying them around. I have a patch in work which does just that (https://bugs.openjdk.java.net/browse/JDK-8261491), but I honestly think adding 200-400K *temporarily* during NMT detail reporting would not be such a big deal. Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge - Merge - Split out display changes - Exclude zero-sized regions from baseline - Start ------------- Changes: https://git.openjdk.java.net/jdk/pull/2428/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2428&range=05 Stats: 10 lines in 2 files changed: 3 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2428/head:pull/2428 PR: https://git.openjdk.java.net/jdk/pull/2428 From stuefe at openjdk.java.net Wed Apr 21 12:28:37 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 12:28:37 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v2] In-Reply-To: References: Message-ID: On Sat, 10 Apr 2021 05:59:43 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Make jcheck happy: remove the TAB > - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels I try to understand this. So: AnonHugePages - number of huge pages mapped into area, THP or explicit ht - this area is mapped with explicit huge pages hg - this area is mapped with madvise(huge_pages), which indicates THP Therefore: !ht && AnonHugePages > 0 -> THP? What confuses me is that the kernel patch you refer to: https://github.com/torvalds/linux/commit/50f8b92f21d23789bd4ada593e8ddc56cc4f79fe sounds like the flag is not passed down to the memory management layer. Would this not effectively switch off THP for the region, and the resulting mapping would use small pages? In which case the failing test would have been correct, since we specified UseTransparentHugePages but it did not work? Sorry for my confusion. ..Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From jbachorik at openjdk.java.net Wed Apr 21 13:17:41 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 21 Apr 2021 13:17:41 GMT Subject: Withdrawn: 8264136: Active processor count may be underreported In-Reply-To: References: Message-ID: <00O8ki5KipZkd7y1eB_rd7-Vdh6Z2B9NBUfvQKYF7jY=.97c9174a-367d-418c-8a6d-eac641c5d28d@github.com> On Wed, 24 Mar 2021 17:08:45 GMT, Jaroslav Bachorik wrote: > ## Current situation > > In cgroups environments the available CPU resources are described by the minimal guaranteed amount and maximal allowed amount (see eg. [this post](https://engineering.squarespace.com/blog/2017/understanding-linux-container-scheduling#:~:text=CPU%20shares%20provide%20tasks%20in,total%20number%20of%20shares%20available.)). > > The current `active_processor_count` computation makes the assumption that the minimal guaranteed amount of CPU resources translates to the number of available CPUs reported by the container. Unfortunately, this is not completely true and a container is free to use whatever CPUs are available leading to the actual CPU usage being higher than the reported number of available CPUs. > > Just for the record, the algorithm is a bit more involved - it computes both values, the one based on the minimal guaranteed amount (if specified) as well as the one based on the maximal allowed amount (again, if specified) and then takes the lesser of the two. In reality, when both parts are set the minimal guaranteed amount will always be less or equal to the maximal allowed amount so, as a simplification, we can consider the minimal guaranteed amount to be the base for the available CPU count calculation if it is set. > > ## Problematic behavior > > For systems with 'elastic' setup where the minimal guaranteed amount and maximal allowed amount are not equal this definition of available CPUs can lead to misconfiguration of anything relying on the reported number of cores - eg. number of GC threads, compiler thread or the fork-join pool size. > > ## Proposed fix > > The proposed fix is to disregard the minimal guaranteed amount in the calculation when `PreferContainerQuotaForCPUCount` JVM flag is set to `true` (currently default). This would allow fallback to the original calculation based on the minimal guaranteed amount by specifying `-XX:-PreferContainerQuotaForCPUCount`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3177 From dcubed at openjdk.java.net Wed Apr 21 13:22:01 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Apr 2021 13:22:01 GMT Subject: RFR: 8257831: Suspend with handshakes [v14] In-Reply-To: References: Message-ID: <39QMhQ-RWdnbK6EAn-fhGZyhjFXL7JcIK-Cu7pPSNOI=.d3cc6af7-792e-467b-aa03-af69ccdcfd5f@github.com> On Wed, 21 Apr 2021 07:59:09 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - Removed double tty lock unlocks > - Fixed comment from Dan and fixed name of handshake > - Merge branch 'master' into SuspendInHandshake > - Fixed DavidH second review > - Fixed nits > - Merge branch 'master' into SuspendInHandshake > - Review fixes 4 > - Fixed flag undef dep + spelling error > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/7146104f...ec344661 Reviewed the v11 and v12 incrementals. Still a thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Wed Apr 21 13:22:01 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 21 Apr 2021 13:22:01 GMT Subject: RFR: 8257831: Suspend with handshakes [v14] In-Reply-To: <39QMhQ-RWdnbK6EAn-fhGZyhjFXL7JcIK-Cu7pPSNOI=.d3cc6af7-792e-467b-aa03-af69ccdcfd5f@github.com> References: <39QMhQ-RWdnbK6EAn-fhGZyhjFXL7JcIK-Cu7pPSNOI=.d3cc6af7-792e-467b-aa03-af69ccdcfd5f@github.com> Message-ID: On Wed, 21 Apr 2021 13:17:02 GMT, Daniel D. Daugherty wrote: > Reviewed the v11 and v12 incrementals. > Still a thumbs up. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rrich at openjdk.java.net Wed Apr 21 13:29:00 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 21 Apr 2021 13:29:00 GMT Subject: RFR: 8257831: Suspend with handshakes [v14] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 07:59:09 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - Removed double tty lock unlocks > - Fixed comment from Dan and fixed name of handshake > - Merge branch 'master' into SuspendInHandshake > - Fixed DavidH second review > - Fixed nits > - Merge branch 'master' into SuspendInHandshake > - Review fixes 4 > - Fixed flag undef dep + spelling error > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/7146104f...ec344661 I've followed the discussion and the increments. Still looks very good to me ?? ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From haosun at openjdk.java.net Wed Apr 21 13:29:47 2021 From: haosun at openjdk.java.net (Hao Sun) Date: Wed, 21 Apr 2021 13:29:47 GMT Subject: RFR: 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion [v2] In-Reply-To: <_9mxRc0vDta95wVWJLFWkO9iRWCt5g1Ni5Dg19xoOKw=.c32e32f7-b564-4a08-9ea9-645d4d9d1442@github.com> References: <_9mxRc0vDta95wVWJLFWkO9iRWCt5g1Ni5Dg19xoOKw=.c32e32f7-b564-4a08-9ea9-645d4d9d1442@github.com> Message-ID: On Tue, 9 Feb 2021 05:17:06 GMT, Hao Sun wrote: >> Making the conversion explicit would fix it. >> >> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. >> Therefore clang-8 and clang-9 are not affected. The flag with similar >> functionality in gcc is '-Wfloat-conversion', but it is not enabled by >> '-Wall' or '-Wextra'. That's why this warning does not appear when >> building with gcc. >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. >> Note that '--with-extra-cxxflags=-Wno-deprecated-copy' should be added when configuration. It's another issue (See JDK-8258010) > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Use static_cast > > To match the style in this file, use static_cast to perform type > casting. Ping? ------------- PR: https://git.openjdk.java.net/jdk/pull/1956 From rehn at openjdk.java.net Wed Apr 21 13:49:54 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 21 Apr 2021 13:49:54 GMT Subject: RFR: 8257831: Suspend with handshakes [v14] In-Reply-To: References: Message-ID: <1XFsfMxTH_U2FAlEBehu-t27WpqjLOmH0CpEWxrOptg=.77cd0dae-d594-4113-bd9b-4ce30cc58d53@github.com> On Wed, 21 Apr 2021 13:25:53 GMT, Richard Reingruber wrote: > I've followed the discussion and the increments. Still looks very good to me Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From dcubed at openjdk.java.net Wed Apr 21 14:17:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Apr 2021 14:17:42 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 [v3] In-Reply-To: <9kvrrZyldW2ygTauBsVGLz2wP1LbXZiWFWaexqcFugs=.1e40b02a-d215-476d-83d4-993552c6c10c@github.com> References: <9kvrrZyldW2ygTauBsVGLz2wP1LbXZiWFWaexqcFugs=.1e40b02a-d215-476d-83d4-993552c6c10c@github.com> Message-ID: On Wed, 21 Apr 2021 10:51:01 GMT, Vladimir Ivanov wrote: >> `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. >> >> The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. >> >> Proposed fix is to start the search from the frame reported by `os::current_frame()`. >> >> Testing: >> - [x] failing test >> - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into 8265218.mh_logging > - Improve the comment > - Merge branch 'master' into 8265218.mh_logging > - Remove from test/hotspot/jtreg/ProblemList-Xcomp.txt > - 8265218: trace_method_handle_stub fails to find calling frame on x86 Thanks for updating the comment. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3554 From coleenp at openjdk.java.net Wed Apr 21 14:19:44 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 21 Apr 2021 14:19:44 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v2] In-Reply-To: References: Message-ID: <6b5Ra0eTA240RpMbkGThOFJ7pRef4v0icuMIX7guLTM=.8f5a5bf9-cd24-472c-a259-29664b0eb903@github.com> On Tue, 20 Apr 2021 22:04:35 GMT, David Holmes wrote: >> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. >> >> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. >> >> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Additional comments on failure modes This looks good to me other than changing asserts to fatals. src/hotspot/share/ci/ciMethod.cpp line 307: > 305: // Failure is only possible for a resource-area OOM, or malformed bytecode > 306: // with verification disabled. > 307: assert(false, "Unexpected exception from compute_map"); Since CATCH was only recently changed from fatal to assert, making these fatal() wouldn't be a change in behavior and that's what this should do. src/hotspot/share/interpreter/oopMapCache.cpp line 115: > 113: // Failure is only possible for a resource-area OOM, or malformed bytecode > 114: // with verification disabled. > 115: assert(false, "Unexpected exception from compute_map"); same here, and below, should be fatal. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3580 From dcubed at openjdk.java.net Wed Apr 21 14:20:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Apr 2021 14:20:37 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 [v3] In-Reply-To: <9kvrrZyldW2ygTauBsVGLz2wP1LbXZiWFWaexqcFugs=.1e40b02a-d215-476d-83d4-993552c6c10c@github.com> References: <9kvrrZyldW2ygTauBsVGLz2wP1LbXZiWFWaexqcFugs=.1e40b02a-d215-476d-83d4-993552c6c10c@github.com> Message-ID: On Wed, 21 Apr 2021 10:51:01 GMT, Vladimir Ivanov wrote: >> `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. >> >> The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. >> >> Proposed fix is to start the search from the frame reported by `os::current_frame()`. >> >> Testing: >> - [x] failing test >> - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into 8265218.mh_logging > - Improve the comment > - Merge branch 'master' into 8265218.mh_logging > - Remove from test/hotspot/jtreg/ProblemList-Xcomp.txt > - 8265218: trace_method_handle_stub fails to find calling frame on x86 JDK-8265218: trace_method_handle_stub fails to find calling frame on x86 was observed in Tier7 and Tier8 so you should do a Tier7 and a Tier8 run on this fix just to be safe. ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From lfoltan at openjdk.java.net Wed Apr 21 14:37:32 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 21 Apr 2021 14:37:32 GMT Subject: RFR: 8265607: Avoid decrementing when no Symbol was created in ~SignatureStream In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 23:32:35 GMT, Claes Redestad wrote: > This patch trivially avoids decrementing refcount on java/lang/Object (a permanent symbol) that is used as a sentinel when the SignatureStream found no Symbols during parse. This is the common case, especially during early VM startup Looks good Claes! Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3596 From mcimadamore at openjdk.java.net Wed Apr 21 14:45:34 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 21 Apr 2021 14:45:34 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v3] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 03:35:06 GMT, Vicente Romero wrote: >> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) >> >> Thanks >> >> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > updating comment after review feedback Compiler changes look good (I have not checked SymbolGenerator). Why were some tests removed? ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3526 From hseigel at openjdk.java.net Wed Apr 21 15:03:52 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 21 Apr 2021 15:03:52 GMT Subject: RFR: 8265490: Unterminated string passed to FindClass() in hotspot test Message-ID: Please review this small fix for JDK-8265490 to null terminate the char* that test FindClassUtf8 passes to JNI_FindClass(). The modified test was run on Linux, Mac OS, and Windows platforms using Mach5 hs-tiers 1 and 2. Thanks, Harold ------------- Commit messages: - 8265490: Unterminated string passed to FindClass() in hotspot test Changes: https://git.openjdk.java.net/jdk/pull/3604/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3604&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265490 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3604.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3604/head:pull/3604 PR: https://git.openjdk.java.net/jdk/pull/3604 From vromero at openjdk.java.net Wed Apr 21 15:13:33 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 21 Apr 2021 15:13:33 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v3] In-Reply-To: References: Message-ID: <2gJQiuoDTZDgr62xRlnZLCoL1-EFjUCSHsKBrSpPV2U=.1918b494-34bb-4f1a-939b-9a931b583117@github.com> On Wed, 21 Apr 2021 14:42:39 GMT, Maurizio Cimadamore wrote: > Compiler changes look good (I have not checked SymbolGenerator). > > Why were some tests removed? thanks for the review. The removed tests were already covered in langtools regression tests, so I only removed duplicated tests ------------- PR: https://git.openjdk.java.net/jdk/pull/3526 From coleenp at openjdk.java.net Wed Apr 21 15:24:32 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 21 Apr 2021 15:24:32 GMT Subject: RFR: 8265490: Unterminated string passed to FindClass() in hotspot test In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:57:09 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8265490 to null terminate the char* that test FindClassUtf8 passes to JNI_FindClass(). The modified test was run on Linux, Mac OS, and Windows platforms using Mach5 hs-tiers 1 and 2. > > Thanks, Harold Looks good plus trivial. Thanks for fixing this. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3604 From coleenp at openjdk.java.net Wed Apr 21 15:30:34 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 21 Apr 2021 15:30:34 GMT Subject: RFR: 8265607: Avoid decrementing when no Symbol was created in ~SignatureStream In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 23:32:35 GMT, Claes Redestad wrote: > This patch trivially avoids decrementing refcount on java/lang/Object (a permanent symbol) that is used as a sentinel when the SignatureStream found no Symbols during parse. This is the common case, especially during early VM startup Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3596 From vlivanov at openjdk.java.net Wed Apr 21 15:32:40 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 21 Apr 2021 15:32:40 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 [v3] In-Reply-To: References: <9kvrrZyldW2ygTauBsVGLz2wP1LbXZiWFWaexqcFugs=.1e40b02a-d215-476d-83d4-993552c6c10c@github.com> Message-ID: On Wed, 21 Apr 2021 14:17:24 GMT, Daniel D. Daugherty wrote: > JDK-8265218: trace_method_handle_stub fails to find calling frame on x86 > was observed in Tier7 and Tier8 so you should do a Tier7 and a Tier8 run > on this fix just to be safe. I definitely can, but it looks like a waste of resources because: (1) I was able to locally reproduce the failure and verified the patch fixes it; (2) I did much more extensive testing: ran hs-tier1 and hs-tier2 w/ `-Xlog:methodhandles=trace` ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From vlivanov at openjdk.java.net Wed Apr 21 15:32:43 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 21 Apr 2021 15:32:43 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 [v3] In-Reply-To: <9kvrrZyldW2ygTauBsVGLz2wP1LbXZiWFWaexqcFugs=.1e40b02a-d215-476d-83d4-993552c6c10c@github.com> References: <9kvrrZyldW2ygTauBsVGLz2wP1LbXZiWFWaexqcFugs=.1e40b02a-d215-476d-83d4-993552c6c10c@github.com> Message-ID: On Wed, 21 Apr 2021 10:51:01 GMT, Vladimir Ivanov wrote: >> `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. >> >> The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. >> >> Proposed fix is to start the search from the frame reported by `os::current_frame()`. >> >> Testing: >> - [x] failing test >> - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into 8265218.mh_logging > - Improve the comment > - Merge branch 'master' into 8265218.mh_logging > - Remove from test/hotspot/jtreg/ProblemList-Xcomp.txt > - 8265218: trace_method_handle_stub fails to find calling frame on x86 Thanks for the reviews, David and Dan. ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From stuefe at openjdk.java.net Wed Apr 21 15:34:33 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 15:34:33 GMT Subject: RFR: 8265490: Unterminated string passed to FindClass() in hotspot test In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:57:09 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8265490 to null terminate the char* that test FindClassUtf8 passes to JNI_FindClass(). The modified test was run on Linux, Mac OS, and Windows platforms using Mach5 hs-tiers 1 and 2. > > Thanks, Harold The original code was interesting :) but beside fixing the zero termination issue, your version is also endian-safe. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3604 From dcubed at openjdk.java.net Wed Apr 21 15:56:36 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Apr 2021 15:56:36 GMT Subject: RFR: 8265218: trace_method_handle_stub fails to find calling frame on x86 [v3] In-Reply-To: References: <9kvrrZyldW2ygTauBsVGLz2wP1LbXZiWFWaexqcFugs=.1e40b02a-d215-476d-83d4-993552c6c10c@github.com> Message-ID: On Wed, 21 Apr 2021 15:29:22 GMT, Vladimir Ivanov wrote: >> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' into 8265218.mh_logging >> - Improve the comment >> - Merge branch 'master' into 8265218.mh_logging >> - Remove from test/hotspot/jtreg/ProblemList-Xcomp.txt >> - 8265218: trace_method_handle_stub fails to find calling frame on x86 > > Thanks for the reviews, David and Dan. @iwanowww - If you are convinced that you've covered the failure modes reported in Tier7 and Tier8 testing, then I'm okay with you skipping those Tiers. ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From hseigel at openjdk.java.net Wed Apr 21 16:05:37 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 21 Apr 2021 16:05:37 GMT Subject: Integrated: 8265490: Unterminated string passed to FindClass() in hotspot test In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:57:09 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8265490 to null terminate the char* that test FindClassUtf8 passes to JNI_FindClass(). The modified test was run on Linux, Mac OS, and Windows platforms using Mach5 hs-tiers 1 and 2. > > Thanks, Harold This pull request has now been integrated. Changeset: 0136c89c Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/0136c89c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8265490: Unterminated string passed to FindClass() in hotspot test Reviewed-by: coleenp, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/3604 From hseigel at openjdk.java.net Wed Apr 21 16:05:36 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 21 Apr 2021 16:05:36 GMT Subject: RFR: 8265490: Unterminated string passed to FindClass() in hotspot test In-Reply-To: References: Message-ID: <1zu1v4wUaprzokCylqI9c-fptwu2fyYVGHmxAvkkTzc=.df2dde96-c753-435e-a9fc-fae8e41c5e6a@github.com> On Wed, 21 Apr 2021 14:57:09 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8265490 to null terminate the char* that test FindClassUtf8 passes to JNI_FindClass(). The modified test was run on Linux, Mac OS, and Windows platforms using Mach5 hs-tiers 1 and 2. > > Thanks, Harold Thanks Coleen and Thomas for reviewing this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3604 From ccheung at openjdk.java.net Wed Apr 21 16:11:01 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 21 Apr 2021 16:11:01 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive [v3] In-Reply-To: References: Message-ID: > Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. > During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. > Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. > > Passed tiers 1,2,3,4 tests on mach5. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: move the setting of shared old class bit to InstanceKlass::remove_unshareable_info ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3479/files - new: https://git.openjdk.java.net/jdk/pull/3479/files/c93eaedd..a8ddecfe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3479&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3479&range=01-02 Stats: 11 lines in 2 files changed: 6 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3479/head:pull/3479 PR: https://git.openjdk.java.net/jdk/pull/3479 From iklam at openjdk.java.net Wed Apr 21 16:48:45 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 16:48:45 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive [v3] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 16:11:01 GMT, Calvin Cheung wrote: >> Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. >> During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. >> Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. >> >> Passed tiers 1,2,3,4 tests on mach5. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > move the setting of shared old class bit to InstanceKlass::remove_unshareable_info LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3479 From iklam at openjdk.java.net Wed Apr 21 16:55:33 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 16:55:33 GMT Subject: RFR: 8265606: Reduce allocations in AdapterHandlerLibrary::get_adapter In-Reply-To: References: Message-ID: <03P0ng2lXbY9yAOmHLZzgkUKW3LM6xWkf8BjdvYjSF4=.ba75a0b7-0c91-4fe6-a64f-8d7749cc485e@github.com> On Tue, 20 Apr 2021 23:32:32 GMT, Claes Redestad wrote: > Use stack allocated arrays used when looking up and creating adapters. Resource allocate if number of args grows large, which is relatively rare. Changes requested by iklam (Reviewer). src/hotspot/share/runtime/sharedRuntime.cpp line 2964: > 2962: // ResourceObject, so do not put any ResourceMarks in here. > 2963: > 2964: BasicType sig_bt[256]; Was this line changed by mistake? The rest of the PR looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3595 From redestad at openjdk.java.net Wed Apr 21 17:25:34 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 21 Apr 2021 17:25:34 GMT Subject: RFR: 8265606: Reduce allocations in AdapterHandlerLibrary::get_adapter In-Reply-To: <03P0ng2lXbY9yAOmHLZzgkUKW3LM6xWkf8BjdvYjSF4=.ba75a0b7-0c91-4fe6-a64f-8d7749cc485e@github.com> References: <03P0ng2lXbY9yAOmHLZzgkUKW3LM6xWkf8BjdvYjSF4=.ba75a0b7-0c91-4fe6-a64f-8d7749cc485e@github.com> Message-ID: On Wed, 21 Apr 2021 16:51:51 GMT, Ioi Lam wrote: >> Use stack allocated arrays used when looking up and creating adapters. Resource allocate if number of args grows large, which is relatively rare. > > src/hotspot/share/runtime/sharedRuntime.cpp line 2964: > >> 2962: // ResourceObject, so do not put any ResourceMarks in here. >> 2963: >> 2964: BasicType sig_bt[256]; > > Was this line changed by mistake? The rest of the PR looks good to me. It was intentional, but it's also a bit of a scope creep: this method is about creating and returning the VMRegPair array, but it also resource-allocs this sig_bt array and keeps it alive for however long the regs array is kept alive, which means we hold on to a bit more memory for longer for no reason. ------------- PR: https://git.openjdk.java.net/jdk/pull/3595 From hseigel at openjdk.java.net Wed Apr 21 17:37:36 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 21 Apr 2021 17:37:36 GMT Subject: RFR: 8265017: runtime/HiddenClasses/StressHiddenClasses.java timed out on Win* OCI In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 17:15:54 GMT, Harold Seigel wrote: > Please review this small test change to try to prevent test StressHiddenClasses,java from timing out. The change increases the test's timeout and prints some output the could be useful in future timeouts. > > The test was run over 1000 times on Windows with this change without any failures. > > Thanks, Harold Thanks David for reviewing this! I created a new RFE to look into improving this test: JDK-8265694. ------------- PR: https://git.openjdk.java.net/jdk/pull/3574 From hseigel at openjdk.java.net Wed Apr 21 17:37:37 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 21 Apr 2021 17:37:37 GMT Subject: Integrated: 8265017: runtime/HiddenClasses/StressHiddenClasses.java timed out on Win* OCI In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 17:15:54 GMT, Harold Seigel wrote: > Please review this small test change to try to prevent test StressHiddenClasses,java from timing out. The change increases the test's timeout and prints some output the could be useful in future timeouts. > > The test was run over 1000 times on Windows with this change without any failures. > > Thanks, Harold This pull request has now been integrated. Changeset: f45d4609 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/f45d4609 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8265017: runtime/HiddenClasses/StressHiddenClasses.java timed out on Win* OCI Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3574 From pchilanomate at openjdk.java.net Wed Apr 21 17:52:56 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 21 Apr 2021 17:52:56 GMT Subject: RFR: 8265453: SafepointMechanism::should_process() should receive JavaThread* Message-ID: Hi, Please review this cleanup in class SafepointMechanism. Since method should_process() is only called by JavaThreads the check in local_poll() is redundant. It also makes the generated code for should_process() unnecessary long since we only need to check the poll bit. I only had to fix a couple of calls from the zero interpreter that where passing a Thread* instead of a JavaThread*. Tested tier1 in mach5 and that it builds zero. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/3603/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3603&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265453 Stats: 26 lines in 3 files changed: 2 ins; 13 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3603.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3603/head:pull/3603 PR: https://git.openjdk.java.net/jdk/pull/3603 From iklam at openjdk.java.net Wed Apr 21 17:57:33 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 17:57:33 GMT Subject: RFR: 8265606: Reduce allocations in AdapterHandlerLibrary::get_adapter In-Reply-To: References: <03P0ng2lXbY9yAOmHLZzgkUKW3LM6xWkf8BjdvYjSF4=.ba75a0b7-0c91-4fe6-a64f-8d7749cc485e@github.com> Message-ID: On Wed, 21 Apr 2021 17:21:30 GMT, Claes Redestad wrote: >> src/hotspot/share/runtime/sharedRuntime.cpp line 2964: >> >>> 2962: // ResourceObject, so do not put any ResourceMarks in here. >>> 2963: >>> 2964: BasicType sig_bt[256]; >> >> Was this line changed by mistake? The rest of the PR looks good to me. > > It was intentional, but it's also a bit of a scope creep: this method is about creating and returning the VMRegPair array, but it also resource-allocs this sig_bt array and keeps it alive for however long the regs array is kept alive, which means we hold on to a bit more memory for longer for no reason. The think the original code was written to avoid allocating large arrays on the stack. ------------- PR: https://git.openjdk.java.net/jdk/pull/3595 From shade at openjdk.java.net Wed Apr 21 17:58:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 17:58:47 GMT Subject: RFR: 8265690: Use latest base image version in Docker testing Message-ID: Use latest image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. Additional testing: - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes - [x] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass - [x] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass ------------- Commit messages: - 8265690: Use latest base image version in Docker testing Changes: https://git.openjdk.java.net/jdk/pull/3605/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3605&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265690 Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3605.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3605/head:pull/3605 PR: https://git.openjdk.java.net/jdk/pull/3605 From minqi at openjdk.java.net Wed Apr 21 18:26:33 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 21 Apr 2021 18:26:33 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive [v3] In-Reply-To: References: Message-ID: <4YDlN1_M-qpgubP1LhqM_SD7dQ5pjZQTjyJR1kqasuU=.3138cce5-ab61-4051-a81f-8d96a24bd320@github.com> On Wed, 21 Apr 2021 16:11:01 GMT, Calvin Cheung wrote: >> Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. >> During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. >> Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. >> >> Passed tiers 1,2,3,4 tests on mach5. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > move the setting of shared old class bit to InstanceKlass::remove_unshareable_info test/hotspot/jtreg/runtime/cds/appcds/OldSuperInf.java line 56: > 54: OutputAnalyzer output = TestCommon.dump(appJar, appClasses, "-Xlog:class+load,cds=debug,verification=trace"); > 55: TestCommon.checkExecReturn(output, 0, > 56: dynamicMode ? true : false, Why use a ternary operator, is it the variable itself OK here? ------------- PR: https://git.openjdk.java.net/jdk/pull/3479 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 18:29:41 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 18:29:41 GMT Subject: RFR: 8265690: Use latest base image version in Docker testing In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 16:02:55 GMT, Aleksey Shipilev wrote: > Use latest image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. > > Additional testing: > - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes > - [x] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass > - [x] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass Seems reasonable to me. My approval means little however. ?? ------------- Marked as reviewed by mgkwill at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/3605 From cjplummer at openjdk.java.net Wed Apr 21 18:43:40 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 21 Apr 2021 18:43:40 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v20] In-Reply-To: References: <9Q69ICl9o5uaRsoDDEa43b9Vl21lzaZIHe2f8mvQy7c=.b1b36b58-787a-4950-9afe-31ca4c79165b@github.com> Message-ID: <-qf3V7rOYbOMN9Wf0Q4Nnuz8seoJwA6VeUBQgqLVnak=.ace9f2ac-4669-4c2e-990a-1547533094cc@github.com> On Wed, 21 Apr 2021 05:56:21 GMT, Lin Zang wrote: > > My concerns with your proposed testing is that it always targets the same application with the same heap, and does not read/process the hprof file to make sure it is not corrupt. > > Hmm, I agree, I will do more test and update here. Thanks! As for jtreg testing, we have a few heap dumping related tests. I'm not sure how good they are. It would be good to understand what testing we currently do. In addition to jtreg testing, you might want to try just launching some large java apps (netbeans and intellij come to mind), dump their heaps, and then process them with some existing tool. I'm not suggesting this be part of regular testing, but just a sanity check you do on your own before pushing the changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From minqi at openjdk.java.net Wed Apr 21 18:29:32 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 21 Apr 2021 18:29:32 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive [v3] In-Reply-To: References: Message-ID: <9YNuBR8JwBvgXbSowR5giBQcc95hi9SEswbPqTBl7pc=.1bb2aa0a-4bf8-4d98-a423-70d421995a34@github.com> On Wed, 21 Apr 2021 16:11:01 GMT, Calvin Cheung wrote: >> Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. >> During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. >> Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. >> >> Passed tiers 1,2,3,4 tests on mach5. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > move the setting of shared old class bit to InstanceKlass::remove_unshareable_info LGTM, only small nits. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3479 From minqi at openjdk.java.net Wed Apr 21 18:29:32 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 21 Apr 2021 18:29:32 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive [v3] In-Reply-To: References: Message-ID: <9YNuBR8JwBvgXbSowR5giBQcc95hi9SEswbPqTBl7pc=.1bb2aa0a-4bf8-4d98-a423-70d421995a34@github.com> On Wed, 21 Apr 2021 16:11:01 GMT, Calvin Cheung wrote: >> Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. >> During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. >> Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. >> >> Passed tiers 1,2,3,4 tests on mach5. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > move the setting of shared old class bit to InstanceKlass::remove_unshareable_info LGTM, only small nits. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3479 From hseigel at openjdk.java.net Wed Apr 21 18:51:02 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 21 Apr 2021 18:51:02 GMT Subject: RFR: 8263421: Module image file is opened twice during VM startup [v2] In-Reply-To: References: Message-ID: > Please review this fix for JDK-8263421. The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file. The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file. > > This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once. > > The fix also removes some unused code related to module image file processing. > > The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3- > 5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: add jimage_non_null(), modify destructor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3591/files - new: https://git.openjdk.java.net/jdk/pull/3591/files/09060479..5341b1ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3591&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3591&range=00-01 Stats: 21 lines in 2 files changed: 8 ins; 8 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3591/head:pull/3591 PR: https://git.openjdk.java.net/jdk/pull/3591 From redestad at openjdk.java.net Wed Apr 21 19:00:54 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 21 Apr 2021 19:00:54 GMT Subject: RFR: 8265606: Reduce allocations in AdapterHandlerLibrary::get_adapter [v2] In-Reply-To: References: Message-ID: <3pgSxpa9Fi5rMksASh90rjrtTEQuDEmIkZsKAOwa6bw=.4d852260-643c-4447-941e-4cc15d749567@github.com> > Use stack allocated arrays used when looking up and creating adapters. Resource allocate if number of args grows large, which is relatively rare. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Revert find_callee_argument changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3595/files - new: https://git.openjdk.java.net/jdk/pull/3595/files/f820f984..f04d5474 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3595&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3595&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3595.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3595/head:pull/3595 PR: https://git.openjdk.java.net/jdk/pull/3595 From redestad at openjdk.java.net Wed Apr 21 19:00:55 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 21 Apr 2021 19:00:55 GMT Subject: RFR: 8265606: Reduce allocations in AdapterHandlerLibrary::get_adapter [v2] In-Reply-To: References: <03P0ng2lXbY9yAOmHLZzgkUKW3LM6xWkf8BjdvYjSF4=.ba75a0b7-0c91-4fe6-a64f-8d7749cc485e@github.com> Message-ID: On Wed, 21 Apr 2021 17:54:47 GMT, Ioi Lam wrote: >> It was intentional, but it's also a bit of a scope creep: this method is about creating and returning the VMRegPair array, but it also resource-allocs this sig_bt array and keeps it alive for however long the regs array is kept alive, which means we hold on to a bit more memory for longer for no reason. > > The think the original code was written to avoid allocating large arrays on the stack. Ok, I reverted this change. It's not part of anything I know sees much use anyhow. ------------- PR: https://git.openjdk.java.net/jdk/pull/3595 From minqi at openjdk.java.net Wed Apr 21 18:10:34 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 21 Apr 2021 18:10:34 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive [v3] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 16:11:01 GMT, Calvin Cheung wrote: >> Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. >> During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. >> Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. >> >> Passed tiers 1,2,3,4 tests on mach5. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > move the setting of shared old class bit to InstanceKlass::remove_unshareable_info src/hotspot/share/classfile/verifier.cpp line 291: > 289: // However, bytecodes for shared old classes can be verified because > 290: // they have not been rewritten. > 291: (!(klass->is_shared() && klass->is_rewritten())) && the outmost brackets are not necessary. Could your remove it? ------------- PR: https://git.openjdk.java.net/jdk/pull/3479 From dcubed at openjdk.java.net Wed Apr 21 19:17:39 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Apr 2021 19:17:39 GMT Subject: RFR: 8265453: SafepointMechanism::should_process() should receive JavaThread* In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:47:13 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this cleanup in class SafepointMechanism. Since method should_process() is only called by JavaThreads the check in local_poll() is redundant. It also makes the generated code for should_process() unnecessary long since we only need to check the poll bit. I only had to fix a couple of calls from the zero interpreter that where passing a Thread* instead of a JavaThread*. > Tested tier1 in mach5 and that it builds zero. > > Thanks, > Patricio Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3603 From dcubed at openjdk.java.net Wed Apr 21 19:40:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Apr 2021 19:40:34 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating In-Reply-To: References: Message-ID: <7_z9JKf0wDbryySASsNAGbS1laveYYxTbAUNCOxmNwI=.35e24f78-0ebb-4964-ac0a-4b5da5585880@github.com> On Wed, 21 Apr 2021 05:50:01 GMT, David Holmes wrote: >> I'm updating the runtime/Thread/SuspendAtExit.java test: >> >> - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread() >> - switch from java.lang.Thread.resume() to JVM/TI ResumeThread() >> - switch from counter-based to time-based testing >> - improve error checking since we're now using an API with error codes! >> >> I've used this test to stress @robehn's fix for JDK-8257831 using both >> invocation styles for 9 hours each in {fastdebug, release, slowdebug} >> configs without any issues. >> >> I've run the updated test thru Mach5 Tier[134567] testing; one timeout >> was observed in a single Tier6 run on Win-X64. I believe this is a case of >> a lost Thread.interrupt() call. > > test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 90: > >> 88: while (System.currentTimeMillis() < start_time + (timeMax * 1000)) { >> 89: count++; >> 90: SuspendAtExit threads[] = new SuspendAtExit[N_THREADS]; > > Style nit pre-existing: The [] go on the type not the variable. Good catch! As I'm re-reading this code, it occurs to me that I really don't need to create the array of `N_THREADS` any more since we are now time based and we'll create a new Thread in each loop and run it through the gauntlet until times runs out. What do you think about changing `SuspendAtExit[N_THREADS]` into just a single `SuspendAtExit`? > test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 103: > >> 101: // the exitSyncObj.await() call and the SuspendThread() >> 102: // calls will come in during thread exit. >> 103: threads[i].interrupt(); > > Pre-existing: why use interrupt() instead of simply calling countDown() on the latch ?? Hmmm.... I don't remember why I chose to use Thread.interrupt() instead of countDown() when I created these tests for the Thread-SMR project. I'll try switching. > test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 159: > >> 157: "after thread #" + i + >> 158: " has been join()'ed"); >> 159: } > > This is unnecessary, you aren't testing the correctness of Thread.join() here. join() can't return normally if the thread is alive. Okay. Will delete the "late" isAlive() check. > test/hotspot/jtreg/runtime/Thread/libSuspendAtExit.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights reserved. > > Copyright year should just be 2021. I copied this code from another file that is "Copyright (c) 2001, 2021" and renamed just the prefix for the suspendThread() and resumeThread() functions. Agent_OnLoad() is a straight copy. So I think I should keep the copyright as is. ------------- PR: https://git.openjdk.java.net/jdk/pull/3576 From hseigel at openjdk.java.net Wed Apr 21 18:51:02 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 21 Apr 2021 18:51:02 GMT Subject: RFR: 8263421: Module image file is opened twice during VM startup In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 17:44:44 GMT, Harold Seigel wrote: > Please review this fix for JDK-8263421. The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file. The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file. > > This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once. > > The fix also removes some unused code related to module image file processing. > > The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3- > 5 on Linux x64. > > Thanks, Harold Thanks Ioi for looking at this change! I added jimage_non_null() and modified ~ClassPathImageEntry() as you suggested. Could you take at these updated changes? Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/3591 From pchilanomate at openjdk.java.net Wed Apr 21 19:56:34 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 21 Apr 2021 19:56:34 GMT Subject: RFR: 8265453: SafepointMechanism::should_process() should receive JavaThread* In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 19:14:17 GMT, Daniel D. Daugherty wrote: > Thumbs up. Thanks Dan! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3603 From iklam at openjdk.java.net Wed Apr 21 20:59:23 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 20:59:23 GMT Subject: RFR: 8265606: Reduce allocations in AdapterHandlerLibrary::get_adapter [v2] In-Reply-To: <3pgSxpa9Fi5rMksASh90rjrtTEQuDEmIkZsKAOwa6bw=.4d852260-643c-4447-941e-4cc15d749567@github.com> References: <3pgSxpa9Fi5rMksASh90rjrtTEQuDEmIkZsKAOwa6bw=.4d852260-643c-4447-941e-4cc15d749567@github.com> Message-ID: On Wed, 21 Apr 2021 19:00:54 GMT, Claes Redestad wrote: >> Use stack allocated arrays used when looking up and creating adapters. Resource allocate if number of args grows large, which is relatively rare. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Revert find_callee_argument changes Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3595 From iklam at openjdk.java.net Wed Apr 21 21:00:29 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 21:00:29 GMT Subject: RFR: 8263421: Module image file is opened twice during VM startup [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 18:51:02 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8263421. The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file. The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file. >> >> This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once. >> >> The fix also removes some unused code related to module image file processing. >> >> The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3- >> 5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > add jimage_non_null(), modify destructor LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3591 From shade at openjdk.java.net Wed Apr 21 21:04:22 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 21:04:22 GMT Subject: RFR: 8265453: SafepointMechanism::should_process() should receive JavaThread* In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:47:13 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this cleanup in class SafepointMechanism. Since method should_process() is only called by JavaThreads the check in local_poll() is redundant. It also makes the generated code for should_process() unnecessary long since we only need to check the poll bit. I only had to fix a couple of calls from the zero interpreter that where passing a Thread* instead of a JavaThread*. > Tested tier1 in mach5 and that it builds zero. > > Thanks, > Patricio Zero change looks fine. It also passes `bootcycle-images` on Linux Zero x86_64 fastdebug, which is a good sanity test for this code. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3603 From dcubed at openjdk.java.net Wed Apr 21 21:22:50 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Apr 2021 21:22:50 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating [v2] In-Reply-To: References: Message-ID: > I'm updating the runtime/Thread/SuspendAtExit.java test: > > - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread() > - switch from java.lang.Thread.resume() to JVM/TI ResumeThread() > - switch from counter-based to time-based testing > - improve error checking since we're now using an API with error codes! > > I've used this test to stress @robehn's fix for JDK-8257831 using both > invocation styles for 9 hours each in {fastdebug, release, slowdebug} > configs without any issues. > > I've run the updated test thru Mach5 Tier[134567] testing; one timeout > was observed in a single Tier6 run on Win-X64. I believe this is a case of > a lost Thread.interrupt() call. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: dholmes CR changes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3576/files - new: https://git.openjdk.java.net/jdk/pull/3576/files/ed352ea3..8235e5f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3576&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3576&range=00-01 Stats: 90 lines in 1 file changed: 22 ins; 33 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/3576.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3576/head:pull/3576 PR: https://git.openjdk.java.net/jdk/pull/3576 From ccheung at openjdk.java.net Wed Apr 21 22:16:49 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 21 Apr 2021 22:16:49 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive [v4] In-Reply-To: References: Message-ID: > Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. > During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. > Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. > > Passed tiers 1,2,3,4 tests on mach5. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: comment from @yminqi, add comment to the is_old_class(), add the @bug tag to new tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3479/files - new: https://git.openjdk.java.net/jdk/pull/3479/files/a8ddecfe..ea81a6cc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3479&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3479&range=02-03 Stats: 8 lines in 7 files changed: 6 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3479/head:pull/3479 PR: https://git.openjdk.java.net/jdk/pull/3479 From pchilanomate at openjdk.java.net Wed Apr 21 22:17:25 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 21 Apr 2021 22:17:25 GMT Subject: RFR: 8265453: SafepointMechanism::should_process() should receive JavaThread* In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:01:50 GMT, Aleksey Shipilev wrote: > Zero change looks fine. It also passes `bootcycle-images` on Linux Zero x86_64 fastdebug, which is a good sanity test for this code. Great, thanks Aleksey! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3603 From ccheung at openjdk.java.net Wed Apr 21 22:22:23 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 21 Apr 2021 22:22:23 GMT Subject: RFR: 8261090: Store old classfiles in static CDS archive [v3] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 18:07:48 GMT, Yumin Qi wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> move the setting of shared old class bit to InstanceKlass::remove_unshareable_info > > src/hotspot/share/classfile/verifier.cpp line 291: > >> 289: // However, bytecodes for shared old classes can be verified because >> 290: // they have not been rewritten. >> 291: (!(klass->is_shared() && klass->is_rewritten())) && > > the outmost brackets are not necessary. Could your remove it? Fixed. I also removed the extra include of metaspaceShared.hpp. > test/hotspot/jtreg/runtime/cds/appcds/OldSuperInf.java line 56: > >> 54: OutputAnalyzer output = TestCommon.dump(appJar, appClasses, "-Xlog:class+load,cds=debug,verification=trace"); >> 55: TestCommon.checkExecReturn(output, 0, >> 56: dynamicMode ? true : false, > > Why use a ternary operator, is it the variable itself OK here? I prefer to leave it as is because the third arg to `TestCommon.checkExecReturn()` is about whether or not to look for the strings in the subsequent args. Thanks for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3479 From haosun at openjdk.java.net Thu Apr 22 02:09:23 2021 From: haosun at openjdk.java.net (Hao Sun) Date: Thu, 22 Apr 2021 02:09:23 GMT Subject: RFR: 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion [v2] In-Reply-To: References: <_9mxRc0vDta95wVWJLFWkO9iRWCt5g1Ni5Dg19xoOKw=.c32e32f7-b564-4a08-9ea9-645d4d9d1442@github.com> Message-ID: On Thu, 22 Apr 2021 02:04:05 GMT, David Holmes wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Use static_cast >> >> To match the style in this file, use static_cast to perform type >> casting. > > Sorry this slipped through the cracks without getting reviewed. > > The fix seems fine and trivial so you can integrate straight away. > > Thanks, > David Thanks for your review. @dholmes-ora ------------- PR: https://git.openjdk.java.net/jdk/pull/1956 From dholmes at openjdk.java.net Thu Apr 22 02:09:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 02:09:23 GMT Subject: RFR: 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion [v2] In-Reply-To: <_9mxRc0vDta95wVWJLFWkO9iRWCt5g1Ni5Dg19xoOKw=.c32e32f7-b564-4a08-9ea9-645d4d9d1442@github.com> References: <_9mxRc0vDta95wVWJLFWkO9iRWCt5g1Ni5Dg19xoOKw=.c32e32f7-b564-4a08-9ea9-645d4d9d1442@github.com> Message-ID: On Tue, 9 Feb 2021 05:17:06 GMT, Hao Sun wrote: >> Making the conversion explicit would fix it. >> >> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. >> Therefore clang-8 and clang-9 are not affected. The flag with similar >> functionality in gcc is '-Wfloat-conversion', but it is not enabled by >> '-Wall' or '-Wextra'. That's why this warning does not appear when >> building with gcc. >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. >> Note that '--with-extra-cxxflags=-Wno-deprecated-copy' should be added when configuration. It's another issue (See JDK-8258010) > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Use static_cast > > To match the style in this file, use static_cast to perform type > casting. Sorry this slipped through the cracks without getting reviewed. The fix seems fine and trivial so you can integrate straight away. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1956 From dholmes at openjdk.java.net Thu Apr 22 02:28:21 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 02:28:21 GMT Subject: RFR: 8263421: Module image file is opened twice during VM startup [v2] In-Reply-To: References: Message-ID: <0zmKNACX_H2vhEC6SBvcMhe2h-1lAD2VVUjP5anfHhM=.4dc5d7de-a37c-47be-af2b-6557931234da@github.com> On Wed, 21 Apr 2021 18:51:02 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8263421. The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file. The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file. >> >> This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once. >> >> The fix also removes some unused code related to module image file processing. >> >> The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3- >> 5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > add jimage_non_null(), modify destructor Hi Harold, Generally this looks okay. A couple of minor nits. Thanks, David src/hotspot/share/classfile/classLoader.cpp line 112: > 110: > 111: // JimageFile pointer, or null if exploded JDK build. > 112: static JImageFile* JImage_File = NULL; Naming style looks odd here - JImage_file ? _jimage_file ? src/hotspot/share/classfile/classLoader.cpp line 360: > 358: void ClassPathImageEntry::set_jimage(JImageFile* jimage) { > 359: JImage_File = jimage; > 360: } This setter seems overkill, especially when it is only used to clear the field, and there is no setter used when giving the field a real value. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3591 From dholmes at openjdk.java.net Thu Apr 22 02:42:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 02:42:23 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating [v2] In-Reply-To: References: Message-ID: <3ea1rkVUQcFqT8YPeHQvmB0SgCcSYPPwkMab3gajohE=.d3a6c134-68a2-4a43-8ef3-511ed68d3e98@github.com> On Wed, 21 Apr 2021 21:22:50 GMT, Daniel D. Daugherty wrote: >> I'm updating the runtime/Thread/SuspendAtExit.java test: >> >> - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread() >> - switch from java.lang.Thread.resume() to JVM/TI ResumeThread() >> - switch from counter-based to time-based testing >> - improve error checking since we're now using an API with error codes! >> >> I've used this test to stress @robehn's fix for JDK-8257831 using both >> invocation styles for 9 hours each in {fastdebug, release, slowdebug} >> configs without any issues. >> >> I've run the updated test thru Mach5 Tier[134567] testing; one timeout >> was observed in a single Tier6 run on Win-X64. I believe this is a case of >> a lost Thread.interrupt() call. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR changes. Marked as reviewed by dholmes (Reviewer). I managed to lose my review comment when switching between commits :) so I'll add it here. Updates look good. I agree there is no need for the Thread[] any more. Thanks, David test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 38: > 36: private final static String AGENT_LIB = "SuspendAtExit"; > 37: private final static int DEF_TIME_MAX = 30; // default max # secs to test > 38: private final static int N_THREADS = 32; N_THREADS is unused now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3576 From dholmes at openjdk.java.net Thu Apr 22 02:42:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 02:42:24 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating [v2] In-Reply-To: <7_z9JKf0wDbryySASsNAGbS1laveYYxTbAUNCOxmNwI=.35e24f78-0ebb-4964-ac0a-4b5da5585880@github.com> References: <7_z9JKf0wDbryySASsNAGbS1laveYYxTbAUNCOxmNwI=.35e24f78-0ebb-4964-ac0a-4b5da5585880@github.com> Message-ID: On Wed, 21 Apr 2021 19:37:28 GMT, Daniel D. Daugherty wrote: >> test/hotspot/jtreg/runtime/Thread/libSuspendAtExit.cpp line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights reserved. >> >> Copyright year should just be 2021. > > I copied this code from another file that is "Copyright (c) 2001, 2021" > and renamed just the prefix for the suspendThread() and resumeThread() > functions. Agent_OnLoad() is a straight copy. > > So I think I should keep the copyright as is. Okay. I have no idea what is supposed to happen in such cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/3576 From dholmes at openjdk.java.net Thu Apr 22 03:02:22 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 03:02:22 GMT Subject: RFR: 8265453: SafepointMechanism::should_process() should receive JavaThread* In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:47:13 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this cleanup in class SafepointMechanism. Since method should_process() is only called by JavaThreads the check in local_poll() is redundant. It also makes the generated code for should_process() unnecessary long since we only need to check the poll bit. I only had to fix a couple of calls from the zero interpreter that where passing a Thread* instead of a JavaThread*. > Tested tier1 in mach5 and that it builds zero. > > Thanks, > Patricio Hi Patricio, LGTM2! :) Thanks, David src/hotspot/cpu/zero/zeroInterpreter_zero.cpp line 554: > 552: > 553: int ZeroInterpreter::getter_entry(Method* method, intptr_t UNUSED, TRAPS) { > 554: JavaThread* thread = THREAD->as_Java_thread(); This will be unnecessary after my TRAPS change but that is still a little ways off. :) src/hotspot/share/runtime/safepointMechanism.inline.hpp line 67: > 65: return local_poll_armed(thread->as_Java_thread()); > 66: } else { > 67: // If the poll is on a non-java thread we can only check the global state. I had wondered how this case could arise - good to see it gone. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3603 From haosun at openjdk.java.net Thu Apr 22 04:44:23 2021 From: haosun at openjdk.java.net (Hao Sun) Date: Thu, 22 Apr 2021 04:44:23 GMT Subject: Integrated: 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 06:16:43 GMT, Hao Sun wrote: > Making the conversion explicit would fix it. > > Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. > Therefore clang-8 and clang-9 are not affected. The flag with similar > functionality in gcc is '-Wfloat-conversion', but it is not enabled by > '-Wall' or '-Wextra'. That's why this warning does not appear when > building with gcc. > > > Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86-64/AArch64 machines. > Note that '--with-extra-cxxflags=-Wno-deprecated-copy' should be added when configuration. It's another issue (See JDK-8258010) This pull request has now been integrated. Changeset: 28c35aed Author: Hao Sun Committer: David Holmes URL: https://git.openjdk.java.net/jdk/commit/28c35aed Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8259288: Debug build failure with clang-10 due to -Wimplicit-int-float-conversion Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1956 From lzang at openjdk.java.net Thu Apr 22 05:57:21 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 22 Apr 2021 05:57:21 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v20] In-Reply-To: <-qf3V7rOYbOMN9Wf0Q4Nnuz8seoJwA6VeUBQgqLVnak=.ace9f2ac-4669-4c2e-990a-1547533094cc@github.com> References: <9Q69ICl9o5uaRsoDDEa43b9Vl21lzaZIHe2f8mvQy7c=.b1b36b58-787a-4950-9afe-31ca4c79165b@github.com> <-qf3V7rOYbOMN9Wf0Q4Nnuz8seoJwA6VeUBQgqLVnak=.ace9f2ac-4669-4c2e-990a-1547533094cc@github.com> Message-ID: On Wed, 21 Apr 2021 18:40:16 GMT, Chris Plummer wrote: > > > My concerns with your proposed testing is that it always targets the same application with the same heap, and does not read/process the hprof file to make sure it is not corrupt. > > > > > > Hmm, I agree, I will do more test and update here. Thanks! > > As for jtreg testing, we have a few heap dumping related tests. I'm not sure how good they are. It would be good to understand what testing we currently do. > > In addition to jtreg testing, you might want to try just launching some large java apps (netbeans and intellij come to mind), dump their heaps, and then process them with some existing tool. I'm not suggesting this be part of regular testing, but just a sanity check you do on your own before pushing the changes. Thanks a lot for suggestion! I will do these tests and update here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From dholmes at openjdk.java.net Thu Apr 22 07:31:38 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 07:31:38 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v3] In-Reply-To: References: Message-ID: > If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. > > In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. > > This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. > > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Replace assert(false) with fatal() After a number of people examined this code it was decided that the best approach was to re-instate the call to fatal() in product builds, that would have been present in the CATCH macro, until recent changes converted that to an assert(). The code here is not prepared to continue if compute_map fails so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed bytecode where verification has been disabled). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3580/files - new: https://git.openjdk.java.net/jdk/pull/3580/files/264fbea5..926e951c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3580&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3580&range=01-02 Stats: 9 lines in 2 files changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3580.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3580/head:pull/3580 PR: https://git.openjdk.java.net/jdk/pull/3580 From dholmes at openjdk.java.net Thu Apr 22 09:39:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 09:39:52 GMT Subject: RFR: 8257831: Suspend with handshakes [v14] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 07:59:09 GMT, Robbin Ehn wrote: >> A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. >> >> Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). >> Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. >> >> Suspend: >> Requesting thread -> synchronous handshake -> target thread >> Inside synchronus handshake (HandshakeState lock is locked while >> executing any handshake): >> - Set suspended flag >> - Install asynchronous handshake >> >> Target thread -> tries to leave dormant state -> Executes handshakes >> Target only executes asynchronous handshake: >> - While suspended >> - Go to blocked >> - Wait on HandshakeState lock >> >> Resume: >> Resuming thread: >> - Lock HandshakeState lock >> - Clear suspended flag >> - Notify HandshakeState lock >> - Unlock HandshakeState lock >> >> The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. >> >> ---- >> Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. >> >> ---- >> Regarding the changed test, the documentation says: >> "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." >> >> But the code: >> LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); >> err = jvmti->SuspendThreadList(threads_count, threads, results); >> ... >> // Allow the Main thread to inspect the result of tested threads suspension >> agent_unlock(jni); >> >> The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). >> Thus main thread is stuck forever on: >> // Block until the suspender thread competes the tested threads suspension >> agent_lock(jni); >> >> And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. >> >> ---- >> >> This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. >> (Pre-review comments here: >> https://github.com/openjdk/jdk/pull/2625) >> >> ---- >> Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and >> combinations like running with -XX:ZCollectionInterval=0.01 - >> XX:ZFragmentationLimit=0. >> Running above some of above concurrently (load ~240), slow debug, >> etc... > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into SuspendInHandshake > - Merge branch 'master' into SuspendInHandshake > - Removed double tty lock unlocks > - Fixed comment from Dan and fixed name of handshake > - Merge branch 'master' into SuspendInHandshake > - Fixed DavidH second review > - Fixed nits > - Merge branch 'master' into SuspendInHandshake > - Review fixes 4 > - Fixed flag undef dep + spelling error > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/7146104f...ec344661 Approving again for good measure. :) ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3191 From redestad at openjdk.java.net Thu Apr 22 09:56:38 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 22 Apr 2021 09:56:38 GMT Subject: Integrated: 8265607: Avoid decrementing when no Symbol was created in ~SignatureStream In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 23:32:35 GMT, Claes Redestad wrote: > This patch trivially avoids decrementing refcount on java/lang/Object (a permanent symbol) that is used as a sentinel when the SignatureStream found no Symbols during parse. This is the common case, especially during early VM startup This pull request has now been integrated. Changeset: a93d9119 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/a93d9119 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8265607: Avoid decrementing when no Symbol was created in ~SignatureStream Reviewed-by: lfoltan, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3596 From redestad at openjdk.java.net Thu Apr 22 09:56:37 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 22 Apr 2021 09:56:37 GMT Subject: RFR: 8265607: Avoid decrementing when no Symbol was created in ~SignatureStream In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 14:34:47 GMT, Lois Foltan wrote: >> This patch trivially avoids decrementing refcount on java/lang/Object (a permanent symbol) that is used as a sentinel when the SignatureStream found no Symbols during parse. This is the common case, especially during early VM startup > > Looks good Claes! > Lois @lfoltan @coleenp - thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/3596 From rehn at openjdk.java.net Thu Apr 22 10:21:49 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Apr 2021 10:21:49 GMT Subject: RFR: 8257831: Suspend with handshakes [v14] In-Reply-To: References: Message-ID: <-BXdMPWTk0hjRi1OEycWrIdp5w4N8pyNSxCR1Wq74xo=.901d9044-270a-41ae-946e-486c6ccb2589@github.com> On Thu, 22 Apr 2021 09:36:26 GMT, David Holmes wrote: > Approving again for good measure. :) Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From rehn at openjdk.java.net Thu Apr 22 10:35:47 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Apr 2021 10:35:47 GMT Subject: Integrated: 8257831: Suspend with handshakes In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 10:56:23 GMT, Robbin Ehn wrote: > A suspend request is done by handshaking thread target thread(s). When executing the handshake operation we know the target mutator thread is in a dormant state (as in safepoint safe state). We have a guarantee that it will check it's poll before leaving the dormant state. To stop the thread from leaving the the dormant state we install a second asynchronous handshake to be executed by the targeted thread. The asynchronous handshake will wait on a monitor while the thread is suspended. The target thread cannot not leave the dormant state without a resume request. > > Per thread suspend requests are naturally serialized by the per thread HandshakeState lock (we can only execute one handshake at a time per thread). > Instead of having a separate lock we use this to our advantage and use HandshakeState lock for serializing access to the suspend flag and for wait/notify. > > Suspend: > Requesting thread -> synchronous handshake -> target thread > Inside synchronus handshake (HandshakeState lock is locked while > executing any handshake): > - Set suspended flag > - Install asynchronous handshake > > Target thread -> tries to leave dormant state -> Executes handshakes > Target only executes asynchronous handshake: > - While suspended > - Go to blocked > - Wait on HandshakeState lock > > Resume: > Resuming thread: > - Lock HandshakeState lock > - Clear suspended flag > - Notify HandshakeState lock > - Unlock HandshakeState lock > > The "suspend requested" flag is an optimization, without it a dormant thread could be suspended and resumed many times and each would add a new asynchronous handshake. Suspend requested flag means there is already an asynchronous suspend handshake in queue which can be re-used, only the suspend flag needs to be set. > > ---- > Some code can be simplified or done in a smarter way but I refrained from doing such changes instead tried to keep existing code as is as far as possible. This concerns especially raw monitors. > > ---- > Regarding the changed test, the documentation says: > "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it." > > But the code: > LOG("suspendTestedThreads: before JVMTI SuspendThreadList"); > err = jvmti->SuspendThreadList(threads_count, threads, results); > ... > // Allow the Main thread to inspect the result of tested threads suspension > agent_unlock(jni); > > The thread will never return from SuspendThreadList until resumed, so it cannot unlock with agent_unlock(). > Thus main thread is stuck forever on: > // Block until the suspender thread competes the tested threads suspension > agent_lock(jni); > > And never checks and resumes the threads. So I removed that lock instead just sleep and check until all thread have the expected suspended state. > > ---- > > This version already contains updates after pre-review comments from @dcubed-ojdk, @pchilano, @coleenp. > (Pre-review comments here: > https://github.com/openjdk/jdk/pull/2625) > > ---- > Testing t1-t8, nsk_jdi/nsk_jvmti/jdk_jdi/tck, KS24, RunThese and > combinations like running with -XX:ZCollectionInterval=0.01 - > XX:ZFragmentationLimit=0. > Running above some of above concurrently (load ~240), slow debug, > etc... This pull request has now been integrated. Changeset: 86bd44fe Author: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/86bd44fe Stats: 1349 lines in 40 files changed: 271 ins; 882 del; 196 mod 8257831: Suspend with handshakes Reviewed-by: dcubed, rrich, dholmes, pchilanomate, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3191 From shade at openjdk.java.net Thu Apr 22 11:58:26 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Apr 2021 11:58:26 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v2] In-Reply-To: References: Message-ID: <6qiZ7PEvrlz4yQhO2voJBDROhNJ0H97uR1buDLwMFGE=.a0950687-71d1-4973-aaf2-d34904136ecd@github.com> On Sat, 10 Apr 2021 05:59:43 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Make jcheck happy: remove the TAB > - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels (sighs) The recent pull made the test fail again even with this patch. Let me see what is up there... ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From shade at openjdk.java.net Thu Apr 22 12:18:19 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Apr 2021 12:18:19 GMT Subject: RFR: 8265690: Use latest base image version in Docker testing In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 16:02:55 GMT, Aleksey Shipilev wrote: > Use latest image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. > > Additional testing: > - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes > - [x] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass > - [x] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass Turns out, the tests are throwing `SkippedException` on error. This masked the failure to resolve `oraclelinux:latest`... Looking at it a bit more. ------------- PR: https://git.openjdk.java.net/jdk/pull/3605 From vlivanov at openjdk.java.net Thu Apr 22 12:21:25 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 22 Apr 2021 12:21:25 GMT Subject: Integrated: 8265218: trace_method_handle_stub fails to find calling frame on x86 In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 22:50:39 GMT, Vladimir Ivanov wrote: > `trace_method_handle_stub` on x86 tries to dump the frame which initiated the tracing, but fails to find the proper frame when it is the immediate caller. > > The problem is `os::current_frame()` returns the caller (instead of the current frame as the name suggests) and then `os::get_sender_for_C_frame()` steps over one more frame. So, if there are no intermediate frames present, it steps over the desired frame. > > Proposed fix is to start the search from the frame reported by `os::current_frame()`. > > Testing: > - [x] failing test > - [x] hs-precheckin-comp,hs-tier1,hs-tier2 w/ `-Xlog:methodhandles=trace` This pull request has now been integrated. Changeset: e16d568c Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk/commit/e16d568c Stats: 12 lines in 2 files changed: 8 ins; 3 del; 1 mod 8265218: trace_method_handle_stub fails to find calling frame on x86 Reviewed-by: dholmes, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3554 From coleenp at openjdk.java.net Thu Apr 22 12:20:30 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 22 Apr 2021 12:20:30 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v3] In-Reply-To: References: Message-ID: <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com> On Thu, 22 Apr 2021 07:31:38 GMT, David Holmes wrote: >> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. >> >> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. >> >> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Replace assert(false) with fatal() > > After a number of people examined this code it was decided that the best approach was to re-instate > the call to fatal() in product builds, that would have been present in the CATCH macro, until recent > changes converted that to an assert(). The code here is not prepared to continue if compute_map fails > so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed > bytecode where verification has been disabled). Good cleanup! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3580 From shade at openjdk.java.net Thu Apr 22 12:37:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Apr 2021 12:37:43 GMT Subject: RFR: 8265690: Use the latest Ubuntu base image version in Docker testing [v2] In-Reply-To: References: Message-ID: > Use latest Ubuntu base image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. > > Additional testing: > - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes > - [ ] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass > - [ ] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass 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: 8265690: Use latest Ubuntu base image version in Docker testing ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3605/files - new: https://git.openjdk.java.net/jdk/pull/3605/files/d36717b5..ad904a7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3605&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3605&range=00-01 Stats: 869 lines in 84 files changed: 516 ins; 194 del; 159 mod Patch: https://git.openjdk.java.net/jdk/pull/3605.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3605/head:pull/3605 PR: https://git.openjdk.java.net/jdk/pull/3605 From dcubed at openjdk.java.net Thu Apr 22 14:17:23 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Apr 2021 14:17:23 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating [v2] In-Reply-To: <3ea1rkVUQcFqT8YPeHQvmB0SgCcSYPPwkMab3gajohE=.d3a6c134-68a2-4a43-8ef3-511ed68d3e98@github.com> References: <3ea1rkVUQcFqT8YPeHQvmB0SgCcSYPPwkMab3gajohE=.d3a6c134-68a2-4a43-8ef3-511ed68d3e98@github.com> Message-ID: On Thu, 22 Apr 2021 02:35:26 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes CR changes. > > test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 38: > >> 36: private final static String AGENT_LIB = "SuspendAtExit"; >> 37: private final static int DEF_TIME_MAX = 30; // default max # secs to test >> 38: private final static int N_THREADS = 32; > > N_THREADS is unused now. Meant to delete that! Will fix it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3576 From rehn at openjdk.java.net Thu Apr 22 14:17:22 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 22 Apr 2021 14:17:22 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:22:50 GMT, Daniel D. Daugherty wrote: >> I'm updating the runtime/Thread/SuspendAtExit.java test: >> >> - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread() >> - switch from java.lang.Thread.resume() to JVM/TI ResumeThread() >> - switch from counter-based to time-based testing >> - improve error checking since we're now using an API with error codes! >> >> I've used this test to stress @robehn's fix for JDK-8257831 using both >> invocation styles for 9 hours each in {fastdebug, release, slowdebug} >> configs without any issues. >> >> I've run the updated test thru Mach5 Tier[134567] testing; one timeout >> was observed in a single Tier6 run on Win-X64. I believe this is a case of >> a lost Thread.interrupt() call. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR changes. Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3576 From pchilanomate at openjdk.java.net Thu Apr 22 14:18:23 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 22 Apr 2021 14:18:23 GMT Subject: RFR: 8265453: SafepointMechanism::should_process() should receive JavaThread* In-Reply-To: References: Message-ID: <0-5JtlU76U7Pt4QCtjm1_3kOLU8mWiIgskzg7HWTAII=.977a779b-9504-418e-b695-1103e93a122e@github.com> On Thu, 22 Apr 2021 02:59:26 GMT, David Holmes wrote: > Hi Patricio, > > LGTM2! :) > Thanks David! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3603 From pchilanomate at openjdk.java.net Thu Apr 22 14:18:23 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 22 Apr 2021 14:18:23 GMT Subject: Integrated: 8265453: SafepointMechanism::should_process() should receive JavaThread* In-Reply-To: References: Message-ID: <38HPdC_RJaJugJcf1hCELXiGRWBy7xFczB2ZM9JY9bE=.09bb0cb6-c735-4ec1-b1af-fc81476114f4@github.com> On Wed, 21 Apr 2021 14:47:13 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this cleanup in class SafepointMechanism. Since method should_process() is only called by JavaThreads the check in local_poll() is redundant. It also makes the generated code for should_process() unnecessary long since we only need to check the poll bit. I only had to fix a couple of calls from the zero interpreter that where passing a Thread* instead of a JavaThread*. > Tested tier1 in mach5 and that it builds zero. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 6d49cc3b Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/6d49cc3b Stats: 26 lines in 3 files changed: 2 ins; 13 del; 11 mod 8265453: SafepointMechanism::should_process() should receive JavaThread* Reviewed-by: dcubed, shade, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3603 From ccheung at openjdk.java.net Thu Apr 22 15:16:23 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 22 Apr 2021 15:16:23 GMT Subject: Integrated: 8261090: Store old classfiles in static CDS archive In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:14:46 GMT, Calvin Cheung wrote: > Please review this RFE for storing old classfiles with major version < 50 in static CDS archive. > During static CDS dump time, old classes won't be verified/rewritten. They will be verified/rewritten during runtime. > Therefore, the `_constMethod`, `_constants`, and `_cache` of old classes must be stored in the RW region of the archive for runtime rewriting. The `ConstantPool::remove_unshareable_info` will be skipped during dump time and the `ConstantPool::restore_unshareable_info` will be skipped during runtime for old classes. > > Passed tiers 1,2,3,4 tests on mach5. This pull request has now been integrated. Changeset: 94991750 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/94991750 Stats: 911 lines in 29 files changed: 869 ins; 16 del; 26 mod 8261090: Store old classfiles in static CDS archive Reviewed-by: iklam, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/3479 From hseigel at openjdk.java.net Thu Apr 22 15:16:32 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 22 Apr 2021 15:16:32 GMT Subject: RFR: 8265757: stack-use-after-scope in perfMemory_posix.cpp get_user_name_slow() Message-ID: Please review this small change to fix JDK-8265757. The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS aarch64, and Windows. Thanks, Harold ------------- Commit messages: - 8265757: stack-use-after-scope in perfMemory_posix.cpp get_user_name_slow() Changes: https://git.openjdk.java.net/jdk/pull/3630/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3630&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265757 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3630.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3630/head:pull/3630 PR: https://git.openjdk.java.net/jdk/pull/3630 From lfoltan at openjdk.java.net Thu Apr 22 15:25:25 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 22 Apr 2021 15:25:25 GMT Subject: RFR: 8265757: stack-use-after-scope in perfMemory_posix.cpp get_user_name_slow() In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:09:25 GMT, Harold Seigel wrote: > Please review this small change to fix JDK-8265757. The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS aarch64, and Windows. > > Thanks, Harold LGTM. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3630 From dcubed at openjdk.java.net Thu Apr 22 15:39:29 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Apr 2021 15:39:29 GMT Subject: RFR: 8265757: stack-use-after-scope in perfMemory_posix.cpp get_user_name_slow() In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:09:25 GMT, Harold Seigel wrote: > Please review this small change to fix JDK-8265757. The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS aarch64, and Windows. > > Thanks, Harold Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3630 From iklam at openjdk.java.net Thu Apr 22 15:46:22 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 15:46:22 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 07:31:38 GMT, David Holmes wrote: >> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. >> >> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. >> >> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Replace assert(false) with fatal() > > After a number of people examined this code it was decided that the best approach was to re-instate > the call to fatal() in product builds, that would have been present in the CATCH macro, until recent > changes converted that to an assert(). The code here is not prepared to continue if compute_map fails > so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed > bytecode where verification has been disabled). Latest version LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3580 From hseigel at openjdk.java.net Thu Apr 22 17:14:30 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 22 Apr 2021 17:14:30 GMT Subject: RFR: 8265757: stack-use-after-scope in perfMemory_posix.cpp get_user_name_slow() In-Reply-To: References: Message-ID: <5NR4RP4V_NLWqcUWespZNie427K01z2Gf668drKv3Cs=.94c9142b-b468-4686-a700-2635895766d5@github.com> On Thu, 22 Apr 2021 15:09:25 GMT, Harold Seigel wrote: > Please review this small change to fix JDK-8265757. The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS aarch64, and Windows. > > Thanks, Harold Thanks Lois and Dan for the reviews. Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/3630 From dcubed at openjdk.java.net Thu Apr 22 17:20:43 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Apr 2021 17:20:43 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating [v3] In-Reply-To: References: Message-ID: > I'm updating the runtime/Thread/SuspendAtExit.java test: > > - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread() > - switch from java.lang.Thread.resume() to JVM/TI ResumeThread() > - switch from counter-based to time-based testing > - improve error checking since we're now using an API with error codes! > > I've used this test to stress @robehn's fix for JDK-8257831 using both > invocation styles for 9 hours each in {fastdebug, release, slowdebug} > configs without any issues. > > I've run the updated test thru Mach5 Tier[134567] testing; one timeout > was observed in a single Tier6 run on Win-X64. I believe this is a case of > a lost Thread.interrupt() call. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: dholmes CR - delete unused N_THREADS. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3576/files - new: https://git.openjdk.java.net/jdk/pull/3576/files/8235e5f2..a4aac0d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3576&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3576&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3576.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3576/head:pull/3576 PR: https://git.openjdk.java.net/jdk/pull/3576 From hseigel at openjdk.java.net Thu Apr 22 17:42:55 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 22 Apr 2021 17:42:55 GMT Subject: RFR: 8263421: Module image file is opened twice during VM startup [v3] In-Reply-To: References: Message-ID: <9vpeEKXWHJ_faNbVKPFv23WiOsHyopQxzHNXt6bEuCQ=.82292c94-3015-4710-b07b-749dcb64c64c@github.com> > Please review this fix for JDK-8263421. The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file. The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file. > > This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once. > > The fix also removes some unused code related to module image file processing. > > The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3- > 5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: removed set_jimage() and renamed JImage_File to JImage_file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3591/files - new: https://git.openjdk.java.net/jdk/pull/3591/files/5341b1ed..47fa218b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3591&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3591&range=01-02 Stats: 13 lines in 2 files changed: 0 ins; 5 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3591/head:pull/3591 PR: https://git.openjdk.java.net/jdk/pull/3591 From pchilanomate at openjdk.java.net Thu Apr 22 17:45:50 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 22 Apr 2021 17:45:50 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v3] In-Reply-To: References: Message-ID: > Hi, > > Please review this small fix. Method check_safepoint_and_suspend_for_native_trans() can just be removed and the code moved directly to check_special_condition_for_native_trans(). The other caller, transition_from_native(), can also just call SafepointMechanism::process_if_requested_with_exit_check() after transitioning to _thread_in_native_trans. Since that removes the only caller of is_suspend_after_native() I also removed it. > I also made a small fix to has_special_runtime_exit_condition(). The compilers were generating three different comparisons for _suspend_flags instead of combining the constant values and doing a single one (I checked this with gcc 10.2 on linux and clang-12 on macos). The extra code was preventing inlining on some cases. For instance, on a Linux release build with gcc 10.2, for the ThreadInVMfromNative constructor, transition_from_native() was being inlined but not process_if_requested_with_exit_check(), so we still required a call for the fast case. The small change to has_special_runtime_exit_condition() fixed that. > Tested in mach5 tiers1-2. > > Thanks, > > Patricio Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into 8265327 - fix typo in comment for check_special_condition_for_native_trans - fix has_special_runtime_exit_condition() to favor inlining - remove is_suspend_after_native() - v1 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3548/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3548&range=02 Stats: 37 lines in 3 files changed: 4 ins; 23 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3548/head:pull/3548 PR: https://git.openjdk.java.net/jdk/pull/3548 From hseigel at openjdk.java.net Thu Apr 22 17:47:04 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 22 Apr 2021 17:47:04 GMT Subject: RFR: 8263421: Module image file is opened twice during VM startup [v3] In-Reply-To: <9vpeEKXWHJ_faNbVKPFv23WiOsHyopQxzHNXt6bEuCQ=.82292c94-3015-4710-b07b-749dcb64c64c@github.com> References: <9vpeEKXWHJ_faNbVKPFv23WiOsHyopQxzHNXt6bEuCQ=.82292c94-3015-4710-b07b-749dcb64c64c@github.com> Message-ID: On Thu, 22 Apr 2021 17:42:55 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8263421. The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file. The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file. >> >> This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once. >> >> The fix also removes some unused code related to module image file processing. >> >> The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3- >> 5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > removed set_jimage() and renamed JImage_File to JImage_file Thanks David for reviewing this. I removed the set_jimage() method and renamed static variable JImage_File to JImage_file. Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/3591 From dcubed at openjdk.java.net Thu Apr 22 17:54:27 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Apr 2021 17:54:27 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 17:45:50 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small fix. Method check_safepoint_and_suspend_for_native_trans() can just be removed and the code moved directly to check_special_condition_for_native_trans(). The other caller, transition_from_native(), can also just call SafepointMechanism::process_if_requested_with_exit_check() after transitioning to _thread_in_native_trans. Since that removes the only caller of is_suspend_after_native() I also removed it. >> I also made a small fix to has_special_runtime_exit_condition(). The compilers were generating three different comparisons for _suspend_flags instead of combining the constant values and doing a single one (I checked this with gcc 10.2 on linux and clang-12 on macos). The extra code was preventing inlining on some cases. For instance, on a Linux release build with gcc 10.2, for the ThreadInVMfromNative constructor, transition_from_native() was being inlined but not process_if_requested_with_exit_check(), so we still required a call for the fast case. The small change to has_special_runtime_exit_condition() fixed that. >> Tested in mach5 tiers1-2. >> >> Thanks, >> >> Patricio > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into 8265327 > - fix typo in comment for check_special_condition_for_native_trans > - fix has_special_runtime_exit_condition() to favor inlining > - remove is_suspend_after_native() > - v1 Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3548 From ccheung at openjdk.java.net Thu Apr 22 20:27:33 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 22 Apr 2021 20:27:33 GMT Subject: RFR: 8264196: Change link_and_cleanup_shared_classes(CATCH) to CHECK Message-ID: Please review this simple fix for passing in CHECK instead of CATCH when calling `link_and_cleanup_shared_classes()` since it could throw an exception. Testing: tiers 1 and 2 on mach5. ------------- Commit messages: - Merge branch 'master' into 8264196-link-and-cleanup-shared-classes - 8264196: Change link_and_cleanup_shared_classes(CATCH) to CHECK Changes: https://git.openjdk.java.net/jdk/pull/3640/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3640&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264196 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3640.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3640/head:pull/3640 PR: https://git.openjdk.java.net/jdk/pull/3640 From dcubed at openjdk.java.net Thu Apr 22 20:41:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Apr 2021 20:41:42 GMT Subject: RFR: 8265786: ProblemList serviceability/sa/sadebugd/DisableRegistryTest.java on ZGC Message-ID: <93s66lybQInA-m-ux9P5Q0fFa2z3V1zczdxramwwGYI=.c072d88d-d236-44a5-9eff-04f8251aaac0@github.com> A trivial fix to ProblemList serviceability/sa/sadebugd/DisableRegistryTest.java on ZGC. ------------- Commit messages: - 8265786: ProblemList serviceability/sa/sadebugd/DisableRegistryTest.java on ZGC Changes: https://git.openjdk.java.net/jdk/pull/3641/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3641&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265786 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3641.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3641/head:pull/3641 PR: https://git.openjdk.java.net/jdk/pull/3641 From darcy at openjdk.java.net Thu Apr 22 20:41:42 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 22 Apr 2021 20:41:42 GMT Subject: RFR: 8265786: ProblemList serviceability/sa/sadebugd/DisableRegistryTest.java on ZGC In-Reply-To: <93s66lybQInA-m-ux9P5Q0fFa2z3V1zczdxramwwGYI=.c072d88d-d236-44a5-9eff-04f8251aaac0@github.com> References: <93s66lybQInA-m-ux9P5Q0fFa2z3V1zczdxramwwGYI=.c072d88d-d236-44a5-9eff-04f8251aaac0@github.com> Message-ID: <5xqsUIn2UVr-3jNeRsyY9-ccGqVTc1q_HutE4--55NM=.338b58dd-4725-46b0-bb0c-862910e660be@github.com> On Thu, 22 Apr 2021 20:32:33 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/sa/sadebugd/DisableRegistryTest.java on ZGC. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3641 From dcubed at openjdk.java.net Thu Apr 22 20:48:25 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Apr 2021 20:48:25 GMT Subject: Integrated: 8265786: ProblemList serviceability/sa/sadebugd/DisableRegistryTest.java on ZGC In-Reply-To: <93s66lybQInA-m-ux9P5Q0fFa2z3V1zczdxramwwGYI=.c072d88d-d236-44a5-9eff-04f8251aaac0@github.com> References: <93s66lybQInA-m-ux9P5Q0fFa2z3V1zczdxramwwGYI=.c072d88d-d236-44a5-9eff-04f8251aaac0@github.com> Message-ID: <6M9SoNqyIVD--eY8uEVNetiDuW2-UzQr7kH9hUIyPIM=.b9be38d6-7302-4423-a6a6-ee3d7be15687@github.com> On Thu, 22 Apr 2021 20:32:33 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/sa/sadebugd/DisableRegistryTest.java on ZGC. This pull request has now been integrated. Changeset: e81baead Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/e81baead Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8265786: ProblemList serviceability/sa/sadebugd/DisableRegistryTest.java on ZGC Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/3641 From dcubed at openjdk.java.net Thu Apr 22 20:48:24 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Apr 2021 20:48:24 GMT Subject: RFR: 8265786: ProblemList serviceability/sa/sadebugd/DisableRegistryTest.java on ZGC In-Reply-To: <5xqsUIn2UVr-3jNeRsyY9-ccGqVTc1q_HutE4--55NM=.338b58dd-4725-46b0-bb0c-862910e660be@github.com> References: <93s66lybQInA-m-ux9P5Q0fFa2z3V1zczdxramwwGYI=.c072d88d-d236-44a5-9eff-04f8251aaac0@github.com> <5xqsUIn2UVr-3jNeRsyY9-ccGqVTc1q_HutE4--55NM=.338b58dd-4725-46b0-bb0c-862910e660be@github.com> Message-ID: On Thu, 22 Apr 2021 20:34:48 GMT, Joe Darcy wrote: >> A trivial fix to ProblemList serviceability/sa/sadebugd/DisableRegistryTest.java on ZGC. > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3641 From minqi at openjdk.java.net Thu Apr 22 20:56:36 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 22 Apr 2021 20:56:36 GMT Subject: RFR: 8264196: Change link_and_cleanup_shared_classes(CATCH) to CHECK In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 20:19:56 GMT, Calvin Cheung wrote: > Please review this simple fix for passing in CHECK instead of CATCH when calling `link_and_cleanup_shared_classes()` since it could throw an exception. > > Testing: tiers 1 and 2 on mach5. LGTM ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3640 From ccheung at openjdk.java.net Thu Apr 22 21:34:24 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 22 Apr 2021 21:34:24 GMT Subject: RFR: 8264196: Change link_and_cleanup_shared_classes(CATCH) to CHECK In-Reply-To: References: Message-ID: <-nPrsi3iGTRIyZWC3HEXTtSwBr1wHdpwYl7MAaONpSc=.f56809cb-69d7-4bd8-b6c0-bd7b018b4604@github.com> On Thu, 22 Apr 2021 20:53:51 GMT, Yumin Qi wrote: >> Please review this simple fix for passing in CHECK instead of CATCH when calling `link_and_cleanup_shared_classes()` since it could throw an exception. >> >> Testing: tiers 1 and 2 on mach5. > > LGTM @yminqi, @iklam, thanks for your quick review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3640 From mseledtsov at openjdk.java.net Thu Apr 22 21:59:49 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Thu, 22 Apr 2021 21:59:49 GMT Subject: RFR: 8265794: Remove ProblemList-non-cds-mode Message-ID: Please review this trivial change. This list has been empty for a long time, and no changes in history since Oct 2018. If we see any issues in non-CDS mode (-Xshare:off) testing in the future (which is very unlikely), we should simply use generic ProblemList to exclude such failing tests. ------------- Commit messages: - Remove ProblemList-non-cds-mode Changes: https://git.openjdk.java.net/jdk/pull/3643/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3643&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265794 Stats: 29 lines in 1 file changed: 0 ins; 29 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3643.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3643/head:pull/3643 PR: https://git.openjdk.java.net/jdk/pull/3643 From mseledtsov at openjdk.java.net Thu Apr 22 21:59:50 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Thu, 22 Apr 2021 21:59:50 GMT Subject: RFR: 8265794: Remove ProblemList-non-cds-mode In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 21:50:52 GMT, Mikhailo Seledtsov wrote: > Please review this trivial change. > > This list has been empty for a long time, and no changes in history since Oct 2018. If we see any issues in non-CDS mode (-Xshare:off) testing in the future (which is very unlikely), we should simply use generic ProblemList to exclude such failing tests. @calvinccheung @iklam could you please review when you have a chance ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3643 From dholmes at openjdk.java.net Thu Apr 22 22:13:25 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 22:13:25 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v3] In-Reply-To: <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com> References: <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com> Message-ID: On Thu, 22 Apr 2021 12:17:57 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace assert(false) with fatal() >> >> After a number of people examined this code it was decided that the best approach was to re-instate >> the call to fatal() in product builds, that would have been present in the CATCH macro, until recent >> changes converted that to an assert(). The code here is not prepared to continue if compute_map fails >> so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed >> bytecode where verification has been disabled). > > Good cleanup! Thanks @coleenp and @iklam for the re-reviews. @dean-long are you also okay with the latest version? It addresses your earlier concern. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3580 From iklam at openjdk.java.net Thu Apr 22 21:08:25 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 21:08:25 GMT Subject: RFR: 8264196: Change link_and_cleanup_shared_classes(CATCH) to CHECK In-Reply-To: References: Message-ID: <0N-6ok7oVA5ICOWDTe4e85ZMP7gPYuVAIDzcmZRm30w=.0dc86d36-4b7d-4c52-8eec-41b7e1285895@github.com> On Thu, 22 Apr 2021 20:19:56 GMT, Calvin Cheung wrote: > Please review this simple fix for passing in CHECK instead of CATCH when calling `link_and_cleanup_shared_classes()` since it could throw an exception. > > Testing: tiers 1 and 2 on mach5. Looks good and trivial. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3640 From iignatyev at openjdk.java.net Thu Apr 22 22:29:25 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Apr 2021 22:29:25 GMT Subject: RFR: 8265794: Remove ProblemList-non-cds-mode In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 21:50:52 GMT, Mikhailo Seledtsov wrote: > Please review this trivial change. > > This list has been empty for a long time, and no changes in history since Oct 2018. If we see any issues in non-CDS mode (-Xshare:off) testing in the future (which is very unlikely), we should simply use generic ProblemList to exclude such failing tests. not that keeping this file costs us a lot, but I'm fine with the change, and I agree that it's a trivial one. -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/3643 From ccheung at openjdk.java.net Thu Apr 22 22:37:25 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 22 Apr 2021 22:37:25 GMT Subject: RFR: 8265794: Remove ProblemList-non-cds-mode In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 21:50:52 GMT, Mikhailo Seledtsov wrote: > Please review this trivial change. > > This list has been empty for a long time, and no changes in history since Oct 2018. If we see any issues in non-CDS mode (-Xshare:off) testing in the future (which is very unlikely), we should simply use generic ProblemList to exclude such failing tests. I think some task definitions refer to this ProblemList and those need to be updated too. ------------- PR: https://git.openjdk.java.net/jdk/pull/3643 From iklam at openjdk.java.net Thu Apr 22 22:44:22 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 22:44:22 GMT Subject: RFR: 8265794: Remove ProblemList-non-cds-mode In-Reply-To: References: Message-ID: <-jvjqZN9GdXt6DdSGKgYNivYXpMpY8t1Q_FD016Wg58=.46bff15c-8f38-4f53-8eff-7f349a6170c3@github.com> On Thu, 22 Apr 2021 21:50:52 GMT, Mikhailo Seledtsov wrote: > Please review this trivial change. > > This list has been empty for a long time, and no changes in history since Oct 2018. If we see any issues in non-CDS mode (-Xshare:off) testing in the future (which is very unlikely), we should simply use generic ProblemList to exclude such failing tests. Look good to me. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3643 From ccheung at openjdk.java.net Thu Apr 22 22:44:23 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 22 Apr 2021 22:44:23 GMT Subject: RFR: 8265794: Remove ProblemList-non-cds-mode In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 21:50:52 GMT, Mikhailo Seledtsov wrote: > Please review this trivial change. > > This list has been empty for a long time, and no changes in history since Oct 2018. If we see any issues in non-CDS mode (-Xshare:off) testing in the future (which is very unlikely), we should simply use generic ProblemList to exclude such failing tests. Looks good. (I saw the changes to the task definitions in another PR.) ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3643 From ccheung at openjdk.java.net Thu Apr 22 23:00:30 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 22 Apr 2021 23:00:30 GMT Subject: Integrated: 8264196: Change link_and_cleanup_shared_classes(CATCH) to CHECK In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 20:19:56 GMT, Calvin Cheung wrote: > Please review this simple fix for passing in CHECK instead of CATCH when calling `link_and_cleanup_shared_classes()` since it could throw an exception. > > Testing: tiers 1 and 2 on mach5. This pull request has now been integrated. Changeset: 7a559140 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/7a559140 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8264196: Change link_and_cleanup_shared_classes(CATCH) to CHECK Reviewed-by: minqi, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3640 From iignatyev at openjdk.java.net Thu Apr 22 23:08:23 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Apr 2021 23:08:23 GMT Subject: RFR: 8265794: Remove ProblemList-non-cds-mode In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 21:50:52 GMT, Mikhailo Seledtsov wrote: > Please review this trivial change. > > This list has been empty for a long time, and no changes in history since Oct 2018. If we see any issues in non-CDS mode (-Xshare:off) testing in the future (which is very unlikely), we should simply use generic ProblemList to exclude such failing tests. Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3643 From dholmes at openjdk.java.net Thu Apr 22 23:11:25 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 23:11:25 GMT Subject: RFR: 8263421: Module image file is opened twice during VM startup [v3] In-Reply-To: <9vpeEKXWHJ_faNbVKPFv23WiOsHyopQxzHNXt6bEuCQ=.82292c94-3015-4710-b07b-749dcb64c64c@github.com> References: <9vpeEKXWHJ_faNbVKPFv23WiOsHyopQxzHNXt6bEuCQ=.82292c94-3015-4710-b07b-749dcb64c64c@github.com> Message-ID: <0WECgwp-vBR0NgnEBbByF6unhGJtULj8XJcn0I162X4=.223847ab-8ff5-4e3c-b8a1-743b08cba711@github.com> On Thu, 22 Apr 2021 17:42:55 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8263421. The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file. The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file. >> >> This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once. >> >> The fix also removes some unused code related to module image file processing. >> >> The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3- >> 5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > removed set_jimage() and renamed JImage_File to JImage_file Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3591 From dholmes at openjdk.java.net Thu Apr 22 23:18:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 23:18:24 GMT Subject: RFR: 8265240: runtime/Thread/SuspendAtExit.java needs updating [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 17:20:43 GMT, Daniel D. Daugherty wrote: >> I'm updating the runtime/Thread/SuspendAtExit.java test: >> >> - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread() >> - switch from java.lang.Thread.resume() to JVM/TI ResumeThread() >> - switch from counter-based to time-based testing >> - improve error checking since we're now using an API with error codes! >> >> I've used this test to stress @robehn's fix for JDK-8257831 using both >> invocation styles for 9 hours each in {fastdebug, release, slowdebug} >> configs without any issues. >> >> I've run the updated test thru Mach5 Tier[134567] testing; one timeout >> was observed in a single Tier6 run on Win-X64. I believe this is a case of >> a lost Thread.interrupt() call. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR - delete unused N_THREADS. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3576 From dholmes at openjdk.java.net Thu Apr 22 23:21:27 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 23:21:27 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 17:45:50 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review this small fix. Method check_safepoint_and_suspend_for_native_trans() can just be removed and the code moved directly to check_special_condition_for_native_trans(). The other caller, transition_from_native(), can also just call SafepointMechanism::process_if_requested_with_exit_check() after transitioning to _thread_in_native_trans. Since that removes the only caller of is_suspend_after_native() I also removed it. >> I also made a small fix to has_special_runtime_exit_condition(). The compilers were generating three different comparisons for _suspend_flags instead of combining the constant values and doing a single one (I checked this with gcc 10.2 on linux and clang-12 on macos). The extra code was preventing inlining on some cases. For instance, on a Linux release build with gcc 10.2, for the ThreadInVMfromNative constructor, transition_from_native() was being inlined but not process_if_requested_with_exit_check(), so we still required a call for the fast case. The small change to has_special_runtime_exit_condition() fixed that. >> Tested in mach5 tiers1-2. >> >> Thanks, >> >> Patricio > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into 8265327 > - fix typo in comment for check_special_condition_for_native_trans > - fix has_special_runtime_exit_condition() to favor inlining > - remove is_suspend_after_native() > - v1 Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3548 From dholmes at openjdk.java.net Thu Apr 22 23:35:29 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 23:35:29 GMT Subject: RFR: 8265757: stack-use-after-scope in perfMemory_posix.cpp get_user_name_slow() In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:09:25 GMT, Harold Seigel wrote: > Please review this small change to fix JDK-8265757. The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS aarch64, and Windows. > > Thanks, Harold Changes requested by dholmes (Reviewer). src/hotspot/os/posix/perfMemory_posix.cpp line 530: > 528: char* oldest_user = NULL; > 529: time_t oldest_ctime = 0; > 530: char buffer[MAXPATHLEN + 1]; If you move this inside the #if defined(LINUX) it would be better. No risk of perturbing other platforms then. ------------- PR: https://git.openjdk.java.net/jdk/pull/3630 From dlong at openjdk.java.net Fri Apr 23 00:48:28 2021 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 23 Apr 2021 00:48:28 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v3] In-Reply-To: <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com> References: <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com> Message-ID: On Thu, 22 Apr 2021 12:17:57 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace assert(false) with fatal() >> >> After a number of people examined this code it was decided that the best approach was to re-instate >> the call to fatal() in product builds, that would have been present in the CATCH macro, until recent >> changes converted that to an assert(). The code here is not prepared to continue if compute_map fails >> so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed >> bytecode where verification has been disabled). > > Good cleanup! > Thanks @coleenp and @iklam for the re-reviews. @dean-long are you also okay with the latest version? It addresses your earlier concern. > > Thanks, > David Yes, looks good! ------------- PR: https://git.openjdk.java.net/jdk/pull/3580 From dlong at openjdk.java.net Fri Apr 23 00:48:27 2021 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 23 Apr 2021 00:48:27 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 07:31:38 GMT, David Holmes wrote: >> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. >> >> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. >> >> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Replace assert(false) with fatal() > > After a number of people examined this code it was decided that the best approach was to re-instate > the call to fatal() in product builds, that would have been present in the CATCH macro, until recent > changes converted that to an assert(). The code here is not prepared to continue if compute_map fails > so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed > bytecode where verification has been disabled). Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3580 From dholmes at openjdk.java.net Fri Apr 23 01:17:26 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Apr 2021 01:17:26 GMT Subject: RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v3] In-Reply-To: References: <7puZy4cP-FJ_9pAqAk4ZxEPtqlGNVpcnzHfyJls2gLs=.46653c57-58ac-4fd9-8ec2-52dd8d55314e@github.com> Message-ID: On Fri, 23 Apr 2021 00:45:46 GMT, Dean Long wrote: >> Good cleanup! > >> Thanks @coleenp and @iklam for the re-reviews. @dean-long are you also okay with the latest version? It addresses your earlier concern. >> >> Thanks, >> David > > Yes, looks good! Thanks @dean-long ! ------------- PR: https://git.openjdk.java.net/jdk/pull/3580 From dholmes at openjdk.java.net Fri Apr 23 01:17:26 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Apr 2021 01:17:26 GMT Subject: Integrated: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers In-Reply-To: References: Message-ID: <_e0sanqzoSSP1_3CfSVt6oQFmA4F3z41pODZUuJN3dg=.7cb33124-bb3b-4bb8-8097-ea24d44ba5d3@github.com> On Mon, 19 Apr 2021 21:38:29 GMT, David Holmes wrote: > If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM. > > In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM. > > This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. > > Testing: tiers 1-3 > > Thanks, > David This pull request has now been integrated. Changeset: 13d32633 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/13d32633 Stats: 44 lines in 4 files changed: 16 ins; 11 del; 17 mod 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers Reviewed-by: iklam, dlong, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3580 From whuang at openjdk.java.net Fri Apr 23 02:14:26 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 23 Apr 2021 02:14:26 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Thu, 8 Apr 2021 04:46:05 GMT, David Holmes wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> add throw exception > > test/hotspot/jtreg/runtime/Nestmates/membership/HostNoNestMember.jcod line 1: > >> 1: class HostNoNestMember { > > This new file needs a copyright notice and GPL header. > > Also please add a comment stating what this jcod file describes - see other jcod files in the directory for example. OK. I will fix that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From vromero at openjdk.java.net Fri Apr 23 02:16:04 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 23 Apr 2021 02:16:04 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v4] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero 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 eight additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - 8260517: Compiler implementation for Sealed Classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/8ebe56fd..43e9cb5f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=02-03 Stats: 40790 lines in 1391 files changed: 8730 ins; 27464 del; 4596 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From whuang at openjdk.java.net Fri Apr 23 02:37:29 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 23 Apr 2021 02:37:29 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: <1eSDgy9iChxAqpiIBPtHRpUooeEmvWNIttx-S_H7g4k=.54d09f9e-fa87-45e8-a76f-361b52f71ef7@github.com> On Thu, 8 Apr 2021 05:22:42 GMT, David Holmes wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> add throw exception > > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 51: > >> 49: public class TestNestHostErrorWithMultiThread { >> 50: >> 51: public static void main(String args[]) throws Throwable { > > "throws Throwable" is only necessary if you want unlisted checked exceptions to propagate. Thank you for your review. `throws Throwable` will be removed in my next commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From whuang at openjdk.java.net Fri Apr 23 02:44:34 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 23 Apr 2021 02:44:34 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Thu, 8 Apr 2021 04:51:01 GMT, David Holmes wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> add throw exception > > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 38: > >> 36: import java.util.concurrent.CountDownLatch; >> 37: >> 38: class HostNoNestMember { > > Please add a comment describing how this class is replaced with the jcode version, and the difference in that version. I split this class into a single file `HostNoNestMember.java` as @hseigel suggested and add a comment. > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 43: > >> 41: } >> 42: >> 43: public int foo() { > > Please call this "test". Sure. Thank you. > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 53: > >> 51: public static void main(String args[]) throws Throwable { >> 52: TestNestHostErrorWithMultiThread t = new TestNestHostErrorWithMultiThread(); >> 53: t.test(); > > There is no need to create an instance - just use a static test method. > > The test code could be placed directly in main in this case. Thank you. It will be deleted in next commit. > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 62: > >> 60: new Thread(() -> { >> 61: try { >> 62: latch.await(); > > Please add a comment: > > // Try to have all threads trigger the nesthost check at the same time Thank you. I will add that in next commit. > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 68: > >> 66: System.out.println("OK - got expected exception: " + expected); >> 67: } catch (InterruptedException e) {} >> 68: }).start(); > > Please extract the logic to a Runnable so that both threads can use that one runnable rather than duplicating the code. Thank you for your review. It will be more clear after extracting the logic. I will refact that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From whuang at openjdk.java.net Fri Apr 23 02:49:24 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 23 Apr 2021 02:49:24 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Mon, 12 Apr 2021 23:50:34 GMT, David Holmes wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> add throw exception > > src/hotspot/share/classfile/systemDictionary.cpp line 1939: > >> 1937: ResolutionErrorEntry* entry = resolution_errors()->find_entry(index, hash, pool, which); >> 1938: if (entry != NULL && entry->nest_host_error() == NULL) { >> 1939: entry->set_nest_host_error(message); > > Please add a comment before line 1939: > // An existing entry means we had a true resolution failure (LinkageError) with our nest host, but we > // still want to add the error message for the higher-level access checks to report. We should > // only reach here under the same error condition, so we can ignore the potential race with setting > // the message. If we see it is already set then we can ignore it. OK. Thank you for your advice. I will add that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From whuang at openjdk.java.net Fri Apr 23 02:52:24 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 23 Apr 2021 02:52:24 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v3] In-Reply-To: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> References: <3_O7tFH1M3ewbWQfahda9LzAikmuWzIFiNexnWXT3Ag=.0a882072-f728-45ec-9362-3f6be481b0f0@github.com> Message-ID: On Thu, 8 Apr 2021 04:38:37 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. The other whole bigger big will be fixed in the other issue. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > add throw exception Thank you for your review. > Class HostNoNestMember could be removed entirely from class TestNestHostErrorWithMultiThread by doing the following: > > Generate a jcod representation for class HostNoNestMember$Member and add it to HostNoNestMember.jcod. I think a java file is more clear? > > Delete class HostNoNestMember from TestNestHostErrorWithMultiThread.java. > I split `HostNoNestMember.java` from `TestNestHostErrorWithMultiThread.java`. > Change the test to compile HostNoNestMember.jcod before compiling TestNestHostErrorWithMultiThread.java. > > Doing this removes the confusion of class HostNoNestMember being compiled twice. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From ccheung at openjdk.java.net Fri Apr 23 02:52:31 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 23 Apr 2021 02:52:31 GMT Subject: RFR: 8265798: Minimal build broken by JDK-8261090 Message-ID: Please review this small patch for fixing broken minimal build. Tests: - [x] linux-x64 minimal vm build locally - [x] builds-tier5 (including linux-x64-zero and linux-x64-zero-debug) - [x] tiers1 and 2 (in progress) ------------- Commit messages: - 8265798: Minimal build broken by JDK-8261090 Changes: https://git.openjdk.java.net/jdk/pull/3646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3646&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265798 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3646/head:pull/3646 PR: https://git.openjdk.java.net/jdk/pull/3646 From iklam at openjdk.java.net Fri Apr 23 03:00:25 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 03:00:25 GMT Subject: RFR: 8265798: Minimal build broken by JDK-8261090 In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 02:45:19 GMT, Calvin Cheung wrote: > Please review this small patch for fixing broken minimal build. > > Tests: > - [x] linux-x64 minimal vm build locally > - [x] builds-tier5 (including linux-x64-zero and linux-x64-zero-debug) > - [x] tiers1 and 2 (in progress) Looks good and trivial. Thanks for fixing this. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3646 From ccheung at openjdk.java.net Fri Apr 23 03:00:25 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 23 Apr 2021 03:00:25 GMT Subject: RFR: 8265798: Minimal build broken by JDK-8261090 In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 02:55:49 GMT, Ioi Lam wrote: >> Please review this small patch for fixing broken minimal build. >> >> Tests: >> - [x] linux-x64 minimal vm build locally >> - [x] builds-tier5 (including linux-x64-zero and linux-x64-zero-debug) >> - [x] tiers1 and 2 (in progress) > > Looks good and trivial. Thanks for fixing this. @iklam, thanks for your quick review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3646 From ccheung at openjdk.java.net Fri Apr 23 03:00:26 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 23 Apr 2021 03:00:26 GMT Subject: Integrated: 8265798: Minimal build broken by JDK-8261090 In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 02:45:19 GMT, Calvin Cheung wrote: > Please review this small patch for fixing broken minimal build. > > Tests: > - [x] linux-x64 minimal vm build locally > - [x] builds-tier5 (including linux-x64-zero and linux-x64-zero-debug) > - [x] tiers1 and 2 (in progress) This pull request has now been integrated. Changeset: a715b09f Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/a715b09f Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod 8265798: Minimal build broken by JDK-8261090 Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3646 From whuang at openjdk.java.net Fri Apr 23 03:02:52 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 23 Apr 2021 03:02:52 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v4] In-Reply-To: References: Message-ID: <8vXrcfOBfRr7UkUZ2PQ-6dPy9Ho498YKhoARuCQAOoI=.ea8d6c64-bdfe-4be0-9d7a-6efb7b4a2a66@github.com> > As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. The other whole bigger big will be fixed in the other issue. Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix bugs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3392/files - new: https://git.openjdk.java.net/jdk/pull/3392/files/b11b658a..b9933eab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=02-03 Stats: 117 lines in 4 files changed: 80 ins; 12 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/3392.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3392/head:pull/3392 PR: https://git.openjdk.java.net/jdk/pull/3392 From stuefe at openjdk.java.net Fri Apr 23 07:34:37 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 23 Apr 2021 07:34:37 GMT Subject: RFR: 8265831: 8257831 broke Windows x86 build Message-ID: Hi, may I please have reviews for this trivial build fix? Thanks! The error is just a missing include. I have no idea why this only breaks x86 though. It has nothing to do with different calling conventions between caller and callee (typical for x86 windows). I just assume the Windows x64 build pulls semaphore.inline.hpp via some other includes. Cheers, Thomas ------------- Commit messages: - start Changes: https://git.openjdk.java.net/jdk/pull/3647/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3647&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265831 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3647.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3647/head:pull/3647 PR: https://git.openjdk.java.net/jdk/pull/3647 From shade at openjdk.java.net Fri Apr 23 07:46:24 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 23 Apr 2021 07:46:24 GMT Subject: RFR: 8265831: 8257831 broke Windows x86 build In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 07:26:52 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this trivial build fix? Thanks! > > The error is just a missing include. I have no idea why this only breaks x86 though. It has nothing to do with different calling conventions between caller and callee (typical for x86 windows). I just assume the Windows x64 build pulls semaphore.inline.hpp via some other includes. > > Cheers, Thomas Looks good and trivial. I also see this failure in my Windows nightlies, and also only on x86_32. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3647 From stuefe at openjdk.java.net Fri Apr 23 07:55:23 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 23 Apr 2021 07:55:23 GMT Subject: RFR: 8265831: 8257831 broke Windows x86 build In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 07:26:52 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this trivial build fix? Thanks! > > The error is just a missing include. I have no idea why this only breaks x86 though. It has nothing to do with different calling conventions between caller and callee (typical for x86 windows). I just assume the Windows x64 build pulls semaphore.inline.hpp via some other includes. > > Cheers, Thomas Thank you Alexey! ------------- PR: https://git.openjdk.java.net/jdk/pull/3647 From redestad at openjdk.java.net Fri Apr 23 13:08:27 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 23 Apr 2021 13:08:27 GMT Subject: Integrated: 8265606: Reduce allocations in AdapterHandlerLibrary::get_adapter In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 23:32:32 GMT, Claes Redestad wrote: > Use stack allocated arrays used when looking up and creating adapters. Resource allocate if number of args grows large, which is relatively rare. This pull request has now been integrated. Changeset: 891f72fe Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/891f72fe Stats: 12 lines in 1 file changed: 7 ins; 0 del; 5 mod 8265606: Reduce allocations in AdapterHandlerLibrary::get_adapter Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3595 From coleenp at openjdk.java.net Fri Apr 23 13:18:41 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 23 Apr 2021 13:18:41 GMT Subject: RFR: 8265682: G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146 Message-ID: This change makes the Mutex constructor stdup the name passed in for the few cases that the name is constructed on the stack. Most names are shorter than 64 characters so it's still a savings. Tested with tier1. ------------- Commit messages: - 8265682: G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146 Changes: https://git.openjdk.java.net/jdk/pull/3639/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3639&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265682 Stats: 27 lines in 2 files changed: 26 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3639.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3639/head:pull/3639 PR: https://git.openjdk.java.net/jdk/pull/3639 From dcubed at openjdk.java.net Fri Apr 23 14:23:30 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Apr 2021 14:23:30 GMT Subject: Integrated: 8265240: runtime/Thread/SuspendAtExit.java needs updating In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:15:18 GMT, Daniel D. Daugherty wrote: > I'm updating the runtime/Thread/SuspendAtExit.java test: > > - switch from java.lang.Thread.suspend() to JVM/TI SuspendThread() > - switch from java.lang.Thread.resume() to JVM/TI ResumeThread() > - switch from counter-based to time-based testing > - improve error checking since we're now using an API with error codes! > > I've used this test to stress @robehn's fix for JDK-8257831 using both > invocation styles for 9 hours each in {fastdebug, release, slowdebug} > configs without any issues. > > I've run the updated test thru Mach5 Tier[134567] testing; one timeout > was observed in a single Tier6 run on Win-X64. I believe this is a case of > a lost Thread.interrupt() call. This pull request has now been integrated. Changeset: c9b70c80 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/c9b70c80 Stats: 186 lines in 2 files changed: 144 ins; 12 del; 30 mod 8265240: runtime/Thread/SuspendAtExit.java needs updating Reviewed-by: rehn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3576 From pchilanomate at openjdk.java.net Fri Apr 23 14:26:28 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 23 Apr 2021 14:26:28 GMT Subject: RFR: 8265327: Remove check_safepoint_and_suspend_for_native_trans() [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 17:51:12 GMT, Daniel D. Daugherty wrote: >> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' into 8265327 >> - fix typo in comment for check_special_condition_for_native_trans >> - fix has_special_runtime_exit_condition() to favor inlining >> - remove is_suspend_after_native() >> - v1 > > Thumbs up. Thanks @dcubed-ojdk, @dholmes-ora and @reinrich for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3548 From pchilanomate at openjdk.java.net Fri Apr 23 14:26:29 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 23 Apr 2021 14:26:29 GMT Subject: Integrated: 8265327: Remove check_safepoint_and_suspend_for_native_trans() In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 16:24:53 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review this small fix. Method check_safepoint_and_suspend_for_native_trans() can just be removed and the code moved directly to check_special_condition_for_native_trans(). The other caller, transition_from_native(), can also just call SafepointMechanism::process_if_requested_with_exit_check() after transitioning to _thread_in_native_trans. Since that removes the only caller of is_suspend_after_native() I also removed it. > I also made a small fix to has_special_runtime_exit_condition(). The compilers were generating three different comparisons for _suspend_flags instead of combining the constant values and doing a single one (I checked this with gcc 10.2 on linux and clang-12 on macos). The extra code was preventing inlining on some cases. For instance, on a Linux release build with gcc 10.2, for the ThreadInVMfromNative constructor, transition_from_native() was being inlined but not process_if_requested_with_exit_check(), so we still required a call for the fast case. The small change to has_special_runtime_exit_condition() fixed that. > Tested in mach5 tiers1-2. > > Thanks, > > Patricio This pull request has now been integrated. Changeset: 8e312297 Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/8e312297 Stats: 37 lines in 3 files changed: 4 ins; 23 del; 10 mod 8265327: Remove check_safepoint_and_suspend_for_native_trans() Reviewed-by: dcubed, dholmes, rrich ------------- PR: https://git.openjdk.java.net/jdk/pull/3548 From iklam at openjdk.java.net Fri Apr 23 16:27:40 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 16:27:40 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v4] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 19:56:45 GMT, Doug Simon wrote: >> While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. >> >> In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. > > Doug Simon has updated the pull request incrementally with two additional commits since the last revision: > > - updated date in copyright > - added blank lines after macros LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3558 From stuefe at openjdk.java.net Fri Apr 23 16:39:38 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 23 Apr 2021 16:39:38 GMT Subject: Integrated: 8265831: 8257831 broke Windows x86 build In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 07:26:52 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this trivial build fix? Thanks! > > The error is just a missing include. I have no idea why this only breaks x86 though. It has nothing to do with different calling conventions between caller and callee (typical for x86 windows). I just assume the Windows x64 build pulls semaphore.inline.hpp via some other includes. > > Cheers, Thomas This pull request has now been integrated. Changeset: ac238701 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/ac238701 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8265831: 8257831 broke Windows x86 build Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/3647 From mseledtsov at openjdk.java.net Fri Apr 23 17:45:29 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 23 Apr 2021 17:45:29 GMT Subject: RFR: 8265794: Remove ProblemList-non-cds-mode In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 21:50:52 GMT, Mikhailo Seledtsov wrote: > Please review this trivial change. > > This list has been empty for a long time, and no changes in history since Oct 2018. If we see any issues in non-CDS mode (-Xshare:off) testing in the future (which is very unlikely), we should simply use generic ProblemList to exclude such failing tests. Calvin, Ioi, Igor, thank you for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3643 From mseledtsov at openjdk.java.net Fri Apr 23 17:45:29 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 23 Apr 2021 17:45:29 GMT Subject: Integrated: 8265794: Remove ProblemList-non-cds-mode In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 21:50:52 GMT, Mikhailo Seledtsov wrote: > Please review this trivial change. > > This list has been empty for a long time, and no changes in history since Oct 2018. If we see any issues in non-CDS mode (-Xshare:off) testing in the future (which is very unlikely), we should simply use generic ProblemList to exclude such failing tests. This pull request has now been integrated. Changeset: d8e638f1 Author: Mikhailo Seledtsov URL: https://git.openjdk.java.net/jdk/commit/d8e638f1 Stats: 29 lines in 1 file changed: 0 ins; 29 del; 0 mod 8265794: Remove ProblemList-non-cds-mode Reviewed-by: ccheung, iklam, iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/3643 From dcubed at openjdk.java.net Fri Apr 23 21:20:35 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Apr 2021 21:20:35 GMT Subject: RFR: 8265880: ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Linux-X64 Message-ID: A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Linux-X64. ------------- Commit messages: - 8265880: ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Linux-X64 Changes: https://git.openjdk.java.net/jdk/pull/3666/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3666&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265880 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3666.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3666/head:pull/3666 PR: https://git.openjdk.java.net/jdk/pull/3666 From rriggs at openjdk.java.net Fri Apr 23 21:31:24 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 23 Apr 2021 21:31:24 GMT Subject: RFR: 8265880: ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Linux-X64 In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 21:14:17 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Linux-X64. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3666 From dcubed at openjdk.java.net Fri Apr 23 21:35:23 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Apr 2021 21:35:23 GMT Subject: RFR: 8265880: ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Linux-X64 In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 21:28:21 GMT, Roger Riggs wrote: >> A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Linux-X64. > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3666 From dcubed at openjdk.java.net Fri Apr 23 21:42:23 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Apr 2021 21:42:23 GMT Subject: Integrated: 8265880: ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Linux-X64 In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 21:14:17 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Linux-X64. This pull request has now been integrated. Changeset: 6803ab2b Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/6803ab2b Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8265880: ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Linux-X64 Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/3666 From dcubed at openjdk.java.net Fri Apr 23 22:15:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Apr 2021 22:15:34 GMT Subject: RFR: 8265884: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 Message-ID: A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64. ------------- Commit messages: - 8265884: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 Changes: https://git.openjdk.java.net/jdk/pull/3667/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3667&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265884 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3667.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3667/head:pull/3667 PR: https://git.openjdk.java.net/jdk/pull/3667 From mikael at openjdk.java.net Fri Apr 23 22:25:23 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 23 Apr 2021 22:25:23 GMT Subject: RFR: 8265884: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 22:09:10 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64. test/hotspot/jtreg/ProblemList.txt line 71: > 69: compiler/whitebox/MakeMethodNotCompilableTest.java 8265360 macosx-aarch64 > 70: > 71: compiler/codecache/jmx/PoolsIndependenceTest.java 8264632 macos-x64 Missing an 'x' - macos*x*-x64 ------------- PR: https://git.openjdk.java.net/jdk/pull/3667 From dnsimon at openjdk.java.net Fri Apr 23 23:35:27 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 23 Apr 2021 23:35:27 GMT Subject: Integrated: 8265403: consolidate definition of CPU features In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 20:18:31 GMT, Doug Simon wrote: > While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. This pull request has now been integrated. Changeset: 5aed446e Author: Doug Simon URL: https://git.openjdk.java.net/jdk/commit/5aed446e Stats: 493 lines in 15 files changed: 146 ins; 235 del; 112 mod 8265403: consolidate definition of CPU features Reviewed-by: kvn, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dnsimon at openjdk.java.net Fri Apr 23 23:35:25 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 23 Apr 2021 23:35:25 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v4] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 20:01:46 GMT, Vladimir Kozlov wrote: >> Doug Simon has updated the pull request incrementally with two additional commits since the last revision: >> >> - updated date in copyright >> - added blank lines after macros > > You need review from Runtime group too. Thanks for the reviews @vnkozlov and @iklam. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dcubed at openjdk.java.net Fri Apr 23 23:35:48 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Apr 2021 23:35:48 GMT Subject: RFR: 8265884: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 In-Reply-To: References: Message-ID: <9v7CinWLuUJ4cCIy2OPpbIlDuthO318ivU6BKd-Ew0o=.06b95eed-d782-463c-bbf3-38f14e733987@github.com> On Fri, 23 Apr 2021 22:09:10 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64. @vidmik - Thanks for catching the typo. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3667 From dcubed at openjdk.java.net Fri Apr 23 23:35:47 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 23 Apr 2021 23:35:47 GMT Subject: RFR: 8265884: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 [v2] In-Reply-To: References: Message-ID: > A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: mikael CR - fix 'macosx' typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3667/files - new: https://git.openjdk.java.net/jdk/pull/3667/files/378751d9..5c0c7998 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3667&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3667&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3667.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3667/head:pull/3667 PR: https://git.openjdk.java.net/jdk/pull/3667 From mikael at openjdk.java.net Sat Apr 24 00:53:23 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Sat, 24 Apr 2021 00:53:23 GMT Subject: RFR: 8265884: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 [v2] In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 23:35:47 GMT, Daniel D. Daugherty wrote: >> A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > mikael CR - fix 'macosx' typo. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3667 From dcubed at openjdk.java.net Sat Apr 24 00:59:23 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 24 Apr 2021 00:59:23 GMT Subject: RFR: 8265884: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 [v2] In-Reply-To: References: Message-ID: <5gNMpQ5un5JH14BglA8_Vbc2fzU-iq12_4ZjvAKISgo=.965d7434-9552-44c5-928e-d18452eb999a@github.com> On Sat, 24 Apr 2021 00:50:20 GMT, Mikael Vidstedt wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> mikael CR - fix 'macosx' typo. > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the re-review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3667 From dcubed at openjdk.java.net Sat Apr 24 00:59:24 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 24 Apr 2021 00:59:24 GMT Subject: Integrated: 8265884: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 22:09:10 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64. This pull request has now been integrated. Changeset: 52f9d229 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/52f9d229 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8265884: ProblemList compiler/codecache/jmx/PoolsIndependenceTest.java on macOS-X64 Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/3667 From dcubed at openjdk.java.net Sat Apr 24 14:41:50 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 24 Apr 2021 14:41:50 GMT Subject: RFR: 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 Message-ID: A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64. It is already ProblemListed on linux-x64. ------------- Commit messages: - Change 'linux-generic' -> 'linux-all'. - 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3668/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3668&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265890 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3668.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3668/head:pull/3668 PR: https://git.openjdk.java.net/jdk/pull/3668 From rriggs at openjdk.java.net Sat Apr 24 15:59:27 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sat, 24 Apr 2021 15:59:27 GMT Subject: RFR: 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 14:35:32 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java > on macOS-X64 and Linux-aarch64. It is already ProblemListed on linux-x64. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3668 From xuelei at openjdk.java.net Sat Apr 24 16:24:27 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 24 Apr 2021 16:24:27 GMT Subject: RFR: 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 14:35:32 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java > on macOS-X64 and Linux-aarch64. It is already ProblemListed on linux-x64. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3668 From dcubed at openjdk.java.net Sun Apr 25 02:57:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 25 Apr 2021 02:57:05 GMT Subject: RFR: 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 15:56:55 GMT, Roger Riggs wrote: >> A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java >> on macOS-X64 and Linux-aarch64. It is already ProblemListed on linux-x64. > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs and @XueleiFan - Thanks for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/3668 From dcubed at openjdk.java.net Sun Apr 25 02:57:06 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 25 Apr 2021 02:57:06 GMT Subject: Integrated: 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 14:35:32 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java > on macOS-X64 and Linux-aarch64. It is already ProblemListed on linux-x64. This pull request has now been integrated. Changeset: f6e22d14 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/f6e22d14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8265890: ProblemList sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java on macOS-X64 and Linux-aarch64 Reviewed-by: rriggs, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/3668 From mli at openjdk.java.net Sun Apr 25 12:47:28 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Sun, 25 Apr 2021 12:47:28 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v7] In-Reply-To: References: Message-ID: On Sun, 7 Feb 2021 12:38:55 GMT, Hamlin Li wrote: >> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > improve jcmd GC.class_histogram to support parallel still waiting for pr #2261 ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From lzang at openjdk.java.net Sun Apr 25 15:01:50 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Sun, 25 Apr 2021 15:01:50 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v7] In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 12:44:09 GMT, Hamlin Li wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> improve jcmd GC.class_histogram to support parallel > > still waiting for pr #2261 Hi @Hamlin-Li @plummercj, @sspitsyn I think maybe this PR can be pushed now because in #2261, we finally decided to not expose `parallel=` option for `jmap -dump`. Do you think it is reasonable? Thanks, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From mli at openjdk.java.net Mon Apr 26 02:22:47 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Mon, 26 Apr 2021 02:22:47 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v8] In-Reply-To: References: Message-ID: > parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: refine help message. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2379/files - new: https://git.openjdk.java.net/jdk/pull/2379/files/ec2324ec..4584c3a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2379&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2379&range=06-07 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2379.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2379/head:pull/2379 PR: https://git.openjdk.java.net/jdk/pull/2379 From mli at openjdk.java.net Mon Apr 26 02:40:30 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Mon, 26 Apr 2021 02:40:30 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v8] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 02:22:47 GMT, Hamlin Li wrote: >> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine help message. Thanks Lin for reminding. ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From stuefe at openjdk.java.net Mon Apr 26 04:59:45 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 26 Apr 2021 04:59:45 GMT Subject: Integrated: JDK-8261238: NMT should not limit baselining by size threshold In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 15:17:56 GMT, Thomas Stuefe wrote: > NMT is a very useful tool to detect memory leaks. Its easy to use, relatively cheap and requires almost zero setup. > > But it artificially limits output to call sites with >1K total memory consumption. That is not helpful, as it confuses the developer and obscures possible memory leaks. It also introduces subtle display errors in that callsites suddenly seem to appear, when comparing to the baseline, with a load of >1K when in fact they had been there already when the baseline was taken. > > I propose to remove the 1K limit completely. This will marginally increase the costs of taking "detail" NMT reports by about 210K for a single report, 420K for a report done using a baseline. > > If this is really a problem preventing us from getting more precise NMT output (really?) there are possibilities to decrease the cost again by sharing call stacks by reference instead of copying them around. I have a patch in work which does just that (https://bugs.openjdk.java.net/browse/JDK-8261491), but I honestly think adding 200-400K *temporarily* during NMT detail reporting would not be such a big deal. This pull request has now been integrated. Changeset: 578a0b3c Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/578a0b3c Stats: 10 lines in 2 files changed: 3 ins; 4 del; 3 mod 8261238: NMT should not limit baselining by size threshold Reviewed-by: zgu, mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/2428 From dholmes at openjdk.java.net Mon Apr 26 07:42:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Apr 2021 07:42:28 GMT Subject: RFR: 8265682: G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146 In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 19:25:50 GMT, Coleen Phillimore wrote: > This change makes the Mutex constructor stdup the name passed in for the few cases that the name is constructed on the stack. Most names are shorter than 64 characters so it's still a savings. > Tested with tier1. Hi Coleen, LGTM. The strdup may have a slight impact on startup, but no more so than the previous implementation, so I think at worst we are back where we were. And we still get the memory savings, which was the primary goal. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3639 From sjohanss at openjdk.java.net Mon Apr 26 07:57:28 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 26 Apr 2021 07:57:28 GMT Subject: RFR: 8265682: G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146 In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 19:25:50 GMT, Coleen Phillimore wrote: > This change makes the Mutex constructor stdup the name passed in for the few cases that the name is constructed on the stack. Most names are shorter than 64 characters so it's still a savings. > Tested with tier1. Looks good. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3639 From sgehwolf at openjdk.java.net Mon Apr 26 10:01:36 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 26 Apr 2021 10:01:36 GMT Subject: RFR: 8265690: Use the latest Ubuntu base image version in Docker testing [v2] In-Reply-To: References: Message-ID: <7VXJtRhui9VyRs0X5fue_52y0iqXEKbmDxNItui-6VQ=.7d168fea-1e0c-4108-8701-34edc15ed4b4@github.com> On Thu, 22 Apr 2021 12:37:43 GMT, Aleksey Shipilev wrote: >> Use latest Ubuntu base image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. >> >> Additional testing: >> - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes >> - [x] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass >> - [x] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass > > 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: > > 8265690: Use latest Ubuntu base image version in Docker testing This looks fine to me. It makes docker tests compatible with more systems by **default**. On the other hand, it'll require for the Oracle config to set `-Djdk.test.docker.image.name=oraclelinux` and `-Djdk.test.docker.image.version=(latest|7.6)` depending on architecture. Paging @iignatev @dholmes-ora for input. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3605 From coleenp at openjdk.java.net Mon Apr 26 12:30:54 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 26 Apr 2021 12:30:54 GMT Subject: RFR: 8265682: G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146 [v2] In-Reply-To: References: Message-ID: > This change makes the Mutex constructor stdup the name passed in for the few cases that the name is constructed on the stack. Most names are shorter than 64 characters so it's still a savings. > Tested with tier1. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: use ASSERT_STREQ ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3639/files - new: https://git.openjdk.java.net/jdk/pull/3639/files/fec5c8af..9baa7ae5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3639&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3639&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3639.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3639/head:pull/3639 PR: https://git.openjdk.java.net/jdk/pull/3639 From lzang at openjdk.java.net Mon Apr 26 12:31:34 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 26 Apr 2021 12:31:34 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v20] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 22:20:17 GMT, Chris Plummer wrote: >> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into par-dump >> - Merge branch 'master' into par-dump >> - Typo fix >> - remove parallel option and dumpheapext command >> - Revert "hide the dumpheapext error message" >> >> This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. >> - resize large object threshold >> - Merge branch 'master' into par-dump >> - Merge branch 'master' into par-dump >> - code clean >> - fix trailing white space issue >> - ... and 15 more: https://git.openjdk.java.net/jdk/compare/e2106d5a...997784b1 > > src/hotspot/share/services/heapDumperCompression.cpp line 240: > >> 238: } >> 239: >> 240: void CompressionBackend::flush_buffer() { > > This method looks to be indentical to `CompressionBackend::deactivate()` except `CompressionBackend::deactivate()` does a couple more tasks at the end. Perhaps `CompressionBackend::deactivate()` should be calling this now. The reason for dup of the code is that both method use the MonitorLocker, but with different scope. Do you think that it is better if I extract those common codes as a method that accept a MonitorLocker as an argument? Such as `flush_buffer_without_lock(MonitorLocker* lock)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From coleenp at openjdk.java.net Mon Apr 26 12:33:25 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 26 Apr 2021 12:33:25 GMT Subject: RFR: 8265682: G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146 [v2] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 12:30:54 GMT, Coleen Phillimore wrote: >> This change makes the Mutex constructor stdup the name passed in for the few cases that the name is constructed on the stack. Most names are shorter than 64 characters so it's still a savings. >> Tested with tier1. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > use ASSERT_STREQ Thanks David and Stefan for the reviews. The name is only used in debugging so if we had any reason to suspect performance regression we could ifdef it. I don't think it's worth doing that and it's good that it would be available in product right now. Kim pointed out offline that I could use ASSERT_STREQ so I made the trivial change in the patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/3639 From lzang at openjdk.java.net Mon Apr 26 12:45:56 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 26 Apr 2021 12:45:56 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v21] In-Reply-To: References: Message-ID: > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Merge branch 'master' into par-dump - refine with several fix - Merge branch 'master' into par-dump - Merge branch 'master' into par-dump - Typo fix - remove parallel option and dumpheapext command - Revert "hide the dumpheapext error message" This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. - resize large object threshold - Merge branch 'master' into par-dump - Merge branch 'master' into par-dump - ... and 17 more: https://git.openjdk.java.net/jdk/compare/c3ac6900...6d14790a ------------- Changes: https://git.openjdk.java.net/jdk/pull/2261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=20 Stats: 861 lines in 6 files changed: 653 ins; 63 del; 145 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From lzang at openjdk.java.net Mon Apr 26 12:48:46 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 26 Apr 2021 12:48:46 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v20] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 12:35:27 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - remove parallel option and dumpheapext command > - Revert "hide the dumpheapext error message" > > This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. > - resize large object threshold > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - code clean > - fix trailing white space issue > - ... and 15 more: https://git.openjdk.java.net/jdk/compare/e2106d5a...997784b1 Update the PR that refined based on comments from Chris. @plummercj , thanks very much for your patience reviewing this pr. Testing is still WIP. I will update the result asap. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From ihse at openjdk.java.net Mon Apr 26 12:56:50 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 26 Apr 2021 12:56:50 GMT Subject: RFR: 8264188: Improve handling of assembly files in the JDK [v3] In-Reply-To: References: Message-ID: > We have a handful of assembly files in the JDK. They have long been left aside, with a "if it ain't broken, don't fix it" attitude. > > In the current panama-vector, there is a lot more assembly files incoming, including for the Windows platforrm, which has not existed for a long time in the JDK. > > It is time to give assembly files some more love and care. This patch cleans up the handling in the build system, and it unifies between .s and .S files. > > For historical reasons, .s has been the suffix used in the posix world to signify assembly output as generated by a compiler, and .S to signify "hand-written" precious assembly. One effect of this is that gcc and clang will run the preprocessor on files named .S but not on files named .s. > > All our files are "hand-written" in this sense, and should have the .S suffix. But not all had. On mac, it was even worse, where the files were named .s but the option `-x assembler-with-cpp` was used to force clang to treat them as .S files instead... This change however made the preprocesser try to parse comments of the form > > # if (a) { > > as preprocessor directives, and balk at them. In one of the files, I had to wrap this in preprocessor comments (`/* ... */`). > > We also had inconsistent handling on dependencies. For preprocessed assembly files, it really makes sense to have dependency tracking, exactly as for C/C++ files. Now the dependency tracking in NativeCompilation is simplified, and applies to all files. (The sole exception is Windows assembly, since masm is unable to output dependency information, even though it is able to include files :-(). > > This patch has been partly written by Sandhya Viswanathan for the panama-vector repo. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into improve-asm-handling - Use OPENJDK_BUILD_CPU_BITS instead - Fix comments that trip up the preprocessor - Transplant over more fixes from panama-vector - -Ta needs to be prefixed to source file - Remove support for non-preprocessed assembly files in gcc/clang - Rename all *.s files to *.S - Port over initial fixes from panama-vector ------------- Changes: https://git.openjdk.java.net/jdk/pull/3198/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3198&range=02 Stats: 78 lines in 12 files changed: 33 ins; 9 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/3198.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3198/head:pull/3198 PR: https://git.openjdk.java.net/jdk/pull/3198 From ihse at openjdk.java.net Mon Apr 26 13:00:33 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 26 Apr 2021 13:00:33 GMT Subject: Integrated: 8264188: Improve handling of assembly files in the JDK In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 16:25:32 GMT, Magnus Ihse Bursie wrote: > We have a handful of assembly files in the JDK. They have long been left aside, with a "if it ain't broken, don't fix it" attitude. > > In the current panama-vector, there is a lot more assembly files incoming, including for the Windows platforrm, which has not existed for a long time in the JDK. > > It is time to give assembly files some more love and care. This patch cleans up the handling in the build system, and it unifies between .s and .S files. > > For historical reasons, .s has been the suffix used in the posix world to signify assembly output as generated by a compiler, and .S to signify "hand-written" precious assembly. One effect of this is that gcc and clang will run the preprocessor on files named .S but not on files named .s. > > All our files are "hand-written" in this sense, and should have the .S suffix. But not all had. On mac, it was even worse, where the files were named .s but the option `-x assembler-with-cpp` was used to force clang to treat them as .S files instead... This change however made the preprocesser try to parse comments of the form > > # if (a) { > > as preprocessor directives, and balk at them. In one of the files, I had to wrap this in preprocessor comments (`/* ... */`). > > We also had inconsistent handling on dependencies. For preprocessed assembly files, it really makes sense to have dependency tracking, exactly as for C/C++ files. Now the dependency tracking in NativeCompilation is simplified, and applies to all files. (The sole exception is Windows assembly, since masm is unable to output dependency information, even though it is able to include files :-(). > > This patch has been partly written by Sandhya Viswanathan for the panama-vector repo. This pull request has now been integrated. Changeset: b9f66d93 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/b9f66d93 Stats: 78 lines in 12 files changed: 33 ins; 9 del; 36 mod 8264188: Improve handling of assembly files in the JDK Co-authored-by: Sandhya Viswanathan Co-authored-by: Magnus Ihse Bursie Reviewed-by: erikj, vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/3198 From sjohanss at openjdk.java.net Mon Apr 26 13:18:30 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 26 Apr 2021 13:18:30 GMT Subject: RFR: 8265682: G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146 [v2] In-Reply-To: References: Message-ID: <8eVzajR8uZRd7Do-LLuH1Q1NDYxpbpabvo426BGw6jg=.57a4ddba-bafb-4972-97b4-a1e6c01d2b3b@github.com> On Mon, 26 Apr 2021 12:30:54 GMT, Coleen Phillimore wrote: >> This change makes the Mutex constructor stdup the name passed in for the few cases that the name is constructed on the stack. Most names are shorter than 64 characters so it's still a savings. >> Tested with tier1. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > use ASSERT_STREQ Still good, I don't think we should `#ifdef` it either. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3639 From coleenp at openjdk.java.net Mon Apr 26 14:26:32 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 26 Apr 2021 14:26:32 GMT Subject: RFR: 8265682: G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146 [v2] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 12:30:54 GMT, Coleen Phillimore wrote: >> This change makes the Mutex constructor stdup the name passed in for the few cases that the name is constructed on the stack. Most names are shorter than 64 characters so it's still a savings. >> Tested with tier1. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > use ASSERT_STREQ Thanks Stefan! ------------- PR: https://git.openjdk.java.net/jdk/pull/3639 From coleenp at openjdk.java.net Mon Apr 26 14:26:34 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 26 Apr 2021 14:26:34 GMT Subject: Integrated: 8265682: G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146 In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 19:25:50 GMT, Coleen Phillimore wrote: > This change makes the Mutex constructor stdup the name passed in for the few cases that the name is constructed on the stack. Most names are shorter than 64 characters so it's still a savings. > Tested with tier1. This pull request has now been integrated. Changeset: 222f9f07 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/222f9f07 Stats: 27 lines in 2 files changed: 26 ins; 0 del; 1 mod 8265682: G1: Mutex::_name dangling in HeapRegionRemSet references after JDK-8264146 Reviewed-by: dholmes, sjohanss ------------- PR: https://git.openjdk.java.net/jdk/pull/3639 From iignatyev at openjdk.java.net Mon Apr 26 15:23:28 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 26 Apr 2021 15:23:28 GMT Subject: RFR: 8265690: Use the latest Ubuntu base image version in Docker testing [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 12:37:43 GMT, Aleksey Shipilev wrote: >> Use latest Ubuntu base image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. >> >> Additional testing: >> - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes >> - [x] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass >> - [x] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass > > 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: > > 8265690: Use latest Ubuntu base image version in Docker testing Severin, thanks for bringing this to our attention. As far as I can see, we explicitly specify `jdk.test.docker.image.(name|version)` properties in all Oracle testing, so the change impacts only local uses, and there it would seem to make it actually easier for people to use. with that being said, I'd like to get an OK from Misha (@mseledts) as he oversees our container testing. Cheers, -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/3605 From mseledtsov at openjdk.java.net Mon Apr 26 17:32:14 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Mon, 26 Apr 2021 17:32:14 GMT Subject: RFR: 8265690: Use the latest Ubuntu base image version in Docker testing [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 12:37:43 GMT, Aleksey Shipilev wrote: >> Use latest Ubuntu base image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. >> >> Additional testing: >> - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes >> - [x] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass >> - [x] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass > > 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: > > 8265690: Use latest Ubuntu base image version in Docker testing As Igor has pointed out, we at Oracle explicitly use jdk.test.docker.image.(name|version) to specify base image+version for container test execution. Hence, in principle I have no objection to this change. Couple of notes though: - this change might potentially affect other parties to OpenJDK that may rely on default base image being OracleLinux, who are not currently using -Ddk.test.docker.image - one of recommended container best practices is to use an explicit version rather than "latest", for more deterministic outcomes ------------- PR: https://git.openjdk.java.net/jdk/pull/3605 From ihse at openjdk.java.net Mon Apr 26 17:35:46 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 26 Apr 2021 17:35:46 GMT Subject: RFR: 8265982: JDK-8264188 breaks build on macOS-aarch64 Message-ID: Unfortunately JDK-8264188 broke the build on macosx-aarch64. The likely culprit for this is that the newly introduced assembly file was named "*.s" instead of "*.S". However, I have still not verified that this (completely) fixes the issue, since my job got stuck in our CI system. Since this is a P1, I wanted to speed on the process by submitting this PR for review even though the results are not yet in. (I will not push until they are.) ------------- Commit messages: - 8265982: JDK-8264188 breaks build on macOS-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3697/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3697&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265982 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3697.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3697/head:pull/3697 PR: https://git.openjdk.java.net/jdk/pull/3697 From ayang at openjdk.java.net Mon Apr 26 17:50:57 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 26 Apr 2021 17:50:57 GMT Subject: RFR: 8265972: Remove declarations with no implementations in javaClasses.hpp Message-ID: Trivial change of removing dead code. ------------- Commit messages: - classes Changes: https://git.openjdk.java.net/jdk/pull/3692/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3692&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265972 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3692.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3692/head:pull/3692 PR: https://git.openjdk.java.net/jdk/pull/3692 From erikj at openjdk.java.net Mon Apr 26 17:58:39 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 26 Apr 2021 17:58:39 GMT Subject: RFR: 8265982: JDK-8264188 breaks build on macOS-aarch64 In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 15:59:48 GMT, Magnus Ihse Bursie wrote: > Unfortunately JDK-8264188 broke the build on macosx-aarch64. > > The likely culprit for this is that the newly introduced assembly file was named "*.s" instead of "*.S". However, I have still not verified that this (completely) fixes the issue, since my job got stuck in our CI system. Since this is a P1, I wanted to speed on the process by submitting this PR for review even though the results are not yet in. (I will not push until they are.) Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3697 From pchilanomate at openjdk.java.net Mon Apr 26 17:59:49 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 26 Apr 2021 17:59:49 GMT Subject: RFR: 8265932: Move safepoint related fields from class Thread to JavaThread Message-ID: Hi, Please review the following change. A left over from?8265453?was moving _poll_data from class Thread to JavaThread. There are also other fields like _no_safepoint_count and _visited_for_critical_count that should be moved. Tested in mach5 tiers 1-5. Tested it builds ppc, arm and s390. Tested it builds in release, optimized and fastdebug modes. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/3695/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3695&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265932 Stats: 239 lines in 30 files changed: 90 ins; 99 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/3695.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3695/head:pull/3695 PR: https://git.openjdk.java.net/jdk/pull/3695 From shade at openjdk.java.net Mon Apr 26 18:01:35 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 26 Apr 2021 18:01:35 GMT Subject: RFR: 8265982: JDK-8264188 breaks build on macOS-aarch64 In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 15:59:48 GMT, Magnus Ihse Bursie wrote: > Unfortunately JDK-8264188 broke the build on macosx-aarch64. > > The likely culprit for this is that the newly introduced assembly file was named "*.s" instead of "*.S". However, I have still not verified that this (completely) fixes the issue, since my job got stuck in our CI system. Since this is a P1, I wanted to speed on the process by submitting this PR for review even though the results are not yet in. (I will not push until they are.) FWIW, macos-aarch64 jobs in GHA are passing. Looks good! ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3697 From ihse at openjdk.java.net Mon Apr 26 18:01:36 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 26 Apr 2021 18:01:36 GMT Subject: Integrated: 8265982: JDK-8264188 breaks build on macOS-aarch64 In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 15:59:48 GMT, Magnus Ihse Bursie wrote: > Unfortunately JDK-8264188 broke the build on macosx-aarch64. > > The likely culprit for this is that the newly introduced assembly file was named "*.s" instead of "*.S". However, I have still not verified that this (completely) fixes the issue, since my job got stuck in our CI system. Since this is a P1, I wanted to speed on the process by submitting this PR for review even though the results are not yet in. (I will not push until they are.) This pull request has now been integrated. Changeset: b524a81a Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/b524a81a Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod 8265982: JDK-8264188 breaks build on macOS-aarch64 Reviewed-by: erikj, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/3697 From coleenp at openjdk.java.net Mon Apr 26 19:00:35 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 26 Apr 2021 19:00:35 GMT Subject: RFR: 8265972: Remove declarations with no implementations in javaClasses.hpp In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 12:37:10 GMT, Albert Mingkun Yang wrote: > Trivial change of removing dead code. Looks good and trivial! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3692 From coleenp at openjdk.java.net Mon Apr 26 20:10:35 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 26 Apr 2021 20:10:35 GMT Subject: RFR: 8265932: Move safepoint related fields from class Thread to JavaThread In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 15:01:41 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following change. A left over from?8265453?was moving _poll_data from class Thread to JavaThread. There are also other fields like _no_safepoint_count and _visited_for_critical_count that should be moved. > Tested in mach5 tiers 1-5. Tested it builds ppc, arm and s390. Tested it builds in release, optimized and fastdebug modes. > > Thanks, > Patricio Looks good to me! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3695 From ayang at openjdk.java.net Mon Apr 26 22:18:35 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 26 Apr 2021 22:18:35 GMT Subject: RFR: 8265972: Remove declarations with no implementations in javaClasses.hpp In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 12:37:10 GMT, Albert Mingkun Yang wrote: > Trivial change of removing dead code. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3692 From ayang at openjdk.java.net Mon Apr 26 22:18:35 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 26 Apr 2021 22:18:35 GMT Subject: Integrated: 8265972: Remove declarations with no implementations in javaClasses.hpp In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 12:37:10 GMT, Albert Mingkun Yang wrote: > Trivial change of removing dead code. This pull request has now been integrated. Changeset: 1d37b984 Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/1d37b984 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod 8265972: Remove declarations with no implementations in javaClasses.hpp Reviewed-by: coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3692 From coleenp at openjdk.java.net Tue Apr 27 00:33:45 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 00:33:45 GMT Subject: RFR: 8265980: Fix systemDictionary and loaderConstraints printing Message-ID: This is a trivial change to fix printing in PrintSystemDictionaryAtExit, see CR for more details. Tested with tier1 on 5 Oracle-supported platforms and manually. ------------- Commit messages: - Remove obsolete assert and move loader_constraints into systemDictionary.cpp - 8265980: Fix systemDictionary and loaderConstraints printing Changes: https://git.openjdk.java.net/jdk/pull/3696/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3696&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265980 Stats: 34 lines in 6 files changed: 12 ins; 16 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3696.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3696/head:pull/3696 PR: https://git.openjdk.java.net/jdk/pull/3696 From coleenp at openjdk.java.net Tue Apr 27 00:40:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 00:40:56 GMT Subject: RFR: 8265980: Fix systemDictionary and loaderConstraints printing [v2] In-Reply-To: References: Message-ID: > This is a trivial change to fix printing in PrintSystemDictionaryAtExit, see CR for more details. > Tested with tier1 on 5 Oracle-supported platforms and manually. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove commented out friend class. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3696/files - new: https://git.openjdk.java.net/jdk/pull/3696/files/9608ab4b..bcc11187 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3696&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3696&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3696.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3696/head:pull/3696 PR: https://git.openjdk.java.net/jdk/pull/3696 From dholmes at openjdk.java.net Tue Apr 27 00:48:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Apr 2021 00:48:33 GMT Subject: RFR: 8265932: Move safepoint related fields from class Thread to JavaThread In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 15:01:41 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following change. A left over from?8265453?was moving _poll_data from class Thread to JavaThread. There are also other fields like _no_safepoint_count and _visited_for_critical_count that should be moved. > Tested in mach5 tiers 1-5. Tested it builds ppc, arm and s390. Tested it builds in release, optimized and fastdebug modes. > > Thanks, > Patricio Hi Patricio, Changes looks good. I had to double-check a few JavaThread conversions actually appear in code that can only be executed by a JavaThread, but they seem okay. One comment below. Thanks, David src/hotspot/share/runtime/mutex.cpp line 423: > 421: > 422: // NSV implied with locking allow_vm_block or !safepoint_check locks. > 423: void Mutex::no_safepoint_verifier(Thread* thread, bool enable) { Wouldn't it have been simpler to add the is_Java_thread() check in here rather than "inlining" this at the call-sites? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3695 From coleenp at openjdk.java.net Tue Apr 27 00:53:36 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 00:53:36 GMT Subject: RFR: 8265980: Fix systemDictionary and loaderConstraints printing [v2] In-Reply-To: References: Message-ID: <4l4P_QTILfMgX0x4Sv2_5wwoaas08jMmqcOBrzAjNGY=.07d3e25b-0165-4508-8ed1-03c5ff44b3d7@github.com> On Tue, 27 Apr 2021 00:40:56 GMT, Coleen Phillimore wrote: >> This is a trivial change to fix printing in PrintSystemDictionaryAtExit, see CR for more details. >> Tested with tier1 on 5 Oracle-supported platforms and manually. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove commented out friend class. Thanks Ioi! ------------- PR: https://git.openjdk.java.net/jdk/pull/3696 From iklam at openjdk.java.net Tue Apr 27 00:53:35 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 27 Apr 2021 00:53:35 GMT Subject: RFR: 8265980: Fix systemDictionary and loaderConstraints printing [v2] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 00:40:56 GMT, Coleen Phillimore wrote: >> This is a trivial change to fix printing in PrintSystemDictionaryAtExit, see CR for more details. >> Tested with tier1 on 5 Oracle-supported platforms and manually. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove commented out friend class. LGTM. Nice clean up. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3696 From mli at openjdk.java.net Tue Apr 27 01:16:42 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 27 Apr 2021 01:16:42 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v8] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 02:22:47 GMT, Hamlin Li wrote: >> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine help message. Seems the build failures on windows are not related to this change. So, I think this change is ready for a reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From patricio.chilano.mateo at oracle.com Tue Apr 27 02:48:19 2021 From: patricio.chilano.mateo at oracle.com (patricio.chilano.mateo at oracle.com) Date: Mon, 26 Apr 2021 23:48:19 -0300 Subject: RFR: 8265932: Move safepoint related fields from class Thread to JavaThread In-Reply-To: References: Message-ID: <03af3a03-d4a2-a4c4-e674-7605566213a4@oracle.com> Hi David, Thanks for looking at this. On 4/26/21 9:48 PM, David Holmes wrote: > Hi Patricio, > > Changes looks good. I had to double-check a few JavaThread conversions actually appear in code that can only be executed by a JavaThread, but they seem okay. > > One comment below. > > Thanks, > David > > src/hotspot/share/runtime/mutex.cpp line 423: > >> 421: >> 422: // NSV implied with locking allow_vm_block or !safepoint_check locks. >> 423: void Mutex::no_safepoint_verifier(Thread* thread, bool enable) { > Wouldn't it have been simpler to add the is_Java_thread() check in here rather than "inlining" this at the call-sites? Since the call can be replaced by just two lines I thought it was better to inline it for readability purposes. I also didn't like the name no_safepoint_verifier() too much since we are not really verifying anything. The verification is done in check_possible_safepoint(). I now see the same issue with NoSafepointVerifier (maybe it should be NoSafepointMark). Anyways, I don't really have a strong opinion about it so I can restore it if you think it's better with no_safepoint_verifier(). Thanks, Patricio > ------------- > > Marked as reviewed by dholmes (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3695 From david.holmes at oracle.com Tue Apr 27 05:05:16 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Apr 2021 15:05:16 +1000 Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API In-Reply-To: References: Message-ID: <74f06fbe-6194-82db-7692-c9ec295e5ac6@oracle.com> Forwarded from hotspot-dev (I didn't see the mailing list selection in time). David -------------- next part -------------- An embedded message was scrubbed... From: David Holmes Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API Date: Tue, 27 Apr 2021 05:01:11 GMT Size: 13398 URL: From david.holmes at oracle.com Tue Apr 27 07:49:31 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Apr 2021 17:49:31 +1000 Subject: RFR: 8265932: Move safepoint related fields from class Thread to JavaThread In-Reply-To: <03af3a03-d4a2-a4c4-e674-7605566213a4@oracle.com> References: <03af3a03-d4a2-a4c4-e674-7605566213a4@oracle.com> Message-ID: <53c49749-f8b7-79a7-629f-61ff32dd14e0@oracle.com> On 27/04/2021 12:48 pm, patricio.chilano.mateo at oracle.com wrote: > Hi David, > > Thanks for looking at this. > > On 4/26/21 9:48 PM, David Holmes wrote: >> Hi Patricio, >> >> Changes looks good. I had to double-check a few JavaThread conversions >> actually appear in code that can only be executed by a JavaThread, but >> they seem okay. >> >> One comment below. >> >> Thanks, >> David >> >> src/hotspot/share/runtime/mutex.cpp line 423: >> >>> 421: >>> 422: // NSV implied with locking allow_vm_block or !safepoint_check >>> locks. >>> 423: void Mutex::no_safepoint_verifier(Thread* thread, bool enable) { >> Wouldn't it have been simpler to add the is_Java_thread() check in >> here rather than "inlining" this at the call-sites? > Since the call can be replaced by just two lines I thought it was better > to inline it for readability purposes. I also didn't like the name > no_safepoint_verifier() too much since we are not really verifying > anything. The verification is done in check_possible_safepoint(). I now > see the same issue with NoSafepointVerifier (maybe it should be > NoSafepointMark). Anyways, I don't really have a strong opinion about it > so I can restore it if you think it's better with no_safepoint_verifier(). The review would have been simpler if this change had not been made, but now that it has ... I don't feel strongly enough to insist it be restored. Thanks, David ----- > Thanks, > Patricio >> ------------- >> >> Marked as reviewed by dholmes (Reviewer). >> >> PR: https://git.openjdk.java.net/jdk/pull/3695 > From shade at openjdk.java.net Tue Apr 27 09:38:38 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 27 Apr 2021 09:38:38 GMT Subject: RFR: 8265690: Use the latest Ubuntu base image version in Docker testing [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 12:37:43 GMT, Aleksey Shipilev wrote: >> Use latest Ubuntu base image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. >> >> Additional testing: >> - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes >> - [x] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass >> - [x] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass > > 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: > > 8265690: Use latest Ubuntu base image version in Docker testing Well, I think `latest` is fine here, and it matches what other arches are doing in the same test. This also helps us not to update the test every time new development environments appear. Stable CIs should probably just set the test properties for the environments that CI servers run. That would also be the way out for those who may potentially run in incompatibilities. I've checked that the more or less wide spectrum of environments is fine. OK for me to push this? ------------- PR: https://git.openjdk.java.net/jdk/pull/3605 From sgehwolf at openjdk.java.net Tue Apr 27 11:57:33 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 27 Apr 2021 11:57:33 GMT Subject: RFR: 8265690: Use the latest Ubuntu base image version in Docker testing [v2] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 09:35:26 GMT, Aleksey Shipilev wrote: > OK for me to push this? Given the feedback we've got, I'd say yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3605 From coleenp at openjdk.java.net Tue Apr 27 12:07:38 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 12:07:38 GMT Subject: Integrated: 8265980: Fix systemDictionary and loaderConstraints printing In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 15:25:54 GMT, Coleen Phillimore wrote: > This is a trivial change to fix printing in PrintSystemDictionaryAtExit, see CR for more details. > Tested with tier1 on 5 Oracle-supported platforms and manually. This pull request has now been integrated. Changeset: e4be9680 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/e4be9680 Stats: 34 lines in 6 files changed: 12 ins; 17 del; 5 mod 8265980: Fix systemDictionary and loaderConstraints printing Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3696 From hseigel at openjdk.java.net Tue Apr 27 12:10:35 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 27 Apr 2021 12:10:35 GMT Subject: RFR: 8265757: stack-use-after-scope in perfMemory_posix.cpp get_user_name_slow() In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:09:25 GMT, Harold Seigel wrote: > Please review this small change to fix JDK-8265757. The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS aarch64, and Windows. > > Thanks, Harold Thanks Lois and Dan for reviewing this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3630 From hseigel at openjdk.java.net Tue Apr 27 12:10:35 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 27 Apr 2021 12:10:35 GMT Subject: Integrated: 8265757: stack-use-after-scope in perfMemory_posix.cpp get_user_name_slow() In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:09:25 GMT, Harold Seigel wrote: > Please review this small change to fix JDK-8265757. The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS aarch64, and Windows. > > Thanks, Harold This pull request has now been integrated. Changeset: 879a77f1 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/879a77f1 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8265757: stack-use-after-scope in perfMemory_posix.cpp get_user_name_slow() Reviewed-by: lfoltan, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3630 From coleenp at openjdk.java.net Tue Apr 27 12:14:37 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 12:14:37 GMT Subject: RFR: 8265932: Move safepoint related fields from class Thread to JavaThread In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 15:01:41 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following change. A left over from?8265453?was moving _poll_data from class Thread to JavaThread. There are also other fields like _no_safepoint_count and _visited_for_critical_count that should be moved. > Tested in mach5 tiers 1-5. Tested it builds ppc, arm and s390. Tested it builds in release, optimized and fastdebug modes. > > Thanks, > Patricio src/hotspot/share/runtime/mutex.cpp line 453: > 451: if (new_owner->is_Java_thread() && _allow_vm_block && this != tty_lock) { > 452: new_owner->as_Java_thread()->inc_no_safepoint_count(); > 453: } I didn't notice this on first pass. I like the change because it was an awkward function anyway because of the enable/disable parameter. ------------- PR: https://git.openjdk.java.net/jdk/pull/3695 From coleenp at openjdk.java.net Tue Apr 27 13:18:35 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 13:18:35 GMT Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 04:47:32 GMT, David Holmes wrote: > We currently have array_klass() and array_klass_or_null(), where the former can throw exceptions and the latter can not. But they both delegate to: > > array_klass_impl(bool or_null, TRAPS) > > which combines both the exception-throwing and non-exception-throwing code into one method declared with TRAPS. To make progress with the change of TRAPS to JavaThread (JDK-8252685) we need to separate these code paths into distinct methods. > > Testing: tiers 1-3 (in progress) > > Thanks, > David This is a nice cleanup. I wish we'd done this years ago! src/hotspot/share/oops/klass.hpp line 525: > 523: virtual Klass* array_klass_impl(TRAPS); > 524: virtual Klass* array_klass_or_null_impl(int rank); > 525: virtual Klass* array_klass_or_null_impl(); I think you should make these pure virtual functions (=0) and remove the bodies in klass.cpp. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3711 From iignatyev at openjdk.java.net Tue Apr 27 13:24:38 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 27 Apr 2021 13:24:38 GMT Subject: RFR: 8265690: Use the latest Ubuntu base image version in Docker testing [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 12:37:43 GMT, Aleksey Shipilev wrote: >> Use latest Ubuntu base image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. >> >> Additional testing: >> - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes >> - [x] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass >> - [x] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass > > 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: > > 8265690: Use latest Ubuntu base image version in Docker testing Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3605 From hseigel at openjdk.java.net Tue Apr 27 13:35:37 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 27 Apr 2021 13:35:37 GMT Subject: RFR: 8263421: Module image file is opened twice during VM startup [v3] In-Reply-To: <9vpeEKXWHJ_faNbVKPFv23WiOsHyopQxzHNXt6bEuCQ=.82292c94-3015-4710-b07b-749dcb64c64c@github.com> References: <9vpeEKXWHJ_faNbVKPFv23WiOsHyopQxzHNXt6bEuCQ=.82292c94-3015-4710-b07b-749dcb64c64c@github.com> Message-ID: <6Z4_UR_81WU1v2YcV2DDAytiRjEpDINgrCebixTohzc=.b1bc5fd1-2e13-4a4a-b7dc-ddd22880ef43@github.com> On Thu, 22 Apr 2021 17:42:55 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8263421. The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file. The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file. >> >> This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once. >> >> The fix also removes some unused code related to module image file processing. >> >> The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3- >> 5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > removed set_jimage() and renamed JImage_File to JImage_file Thanks Ioi and David for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3591 From hseigel at openjdk.java.net Tue Apr 27 13:35:38 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 27 Apr 2021 13:35:38 GMT Subject: Integrated: 8263421: Module image file is opened twice during VM startup In-Reply-To: References: Message-ID: <2WxC7l0epvPxQq7jmIlWuQavif5izOP_sv1MxKsewGg=.2b1e2f18-da83-4dee-9709-635fb1cd788b@github.com> On Tue, 20 Apr 2021 17:44:44 GMT, Harold Seigel wrote: > Please review this fix for JDK-8263421. The fix stores the JImageFile* in a static that gets initialized when lookup_vm_options() opens the module image file. The static JimageFIle* is then used by setup_bootstrap_search_path_impl() when creating the ClassPathImageEntry for the module image file, avoiding having to re-open the module image file. > > This fix moved the creation of the ClassPathImageEntry for the module image file from create_class_path_entry() to setup_bootstrap_search_path_impl() because create_class_path_entry() may try to do this multiple times, but the ClassPathImageEntry for the module image file is only actually created once. > > The fix also removes some unused code related to module image file processing. > > The changes were tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and Mach5 tiers 3- > 5 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: dc323a93 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/dc323a93 Stats: 72 lines in 2 files changed: 20 ins; 29 del; 23 mod 8263421: Module image file is opened twice during VM startup Reviewed-by: iklam, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3591 From pchilanomate at openjdk.java.net Tue Apr 27 14:27:00 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 27 Apr 2021 14:27:00 GMT Subject: RFR: 8265932: Move safepoint related fields from class Thread to JavaThread [v2] In-Reply-To: References: Message-ID: > Hi, > > Please review the following change. A left over from?8265453?was moving _poll_data from class Thread to JavaThread. There are also other fields like _no_safepoint_count and _visited_for_critical_count that should be moved. > Tested in mach5 tiers 1-5. Tested it builds ppc, arm and s390. Tested it builds in release, optimized and fastdebug modes. > > Thanks, > Patricio Patricio Chilano Mateo 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 8265932 - forgot to remove no_safepoint_verifier() declaration - v1 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3695/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3695&range=01 Stats: 239 lines in 30 files changed: 90 ins; 100 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/3695.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3695/head:pull/3695 PR: https://git.openjdk.java.net/jdk/pull/3695 From rschmelter at openjdk.java.net Tue Apr 27 14:43:48 2021 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Tue, 27 Apr 2021 14:43:48 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException Message-ID: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> This fixes a race condition in the CompressionBackend class of the heap dump code. The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. ------------- Commit messages: - Fix punctuation - Simplify code - Fix race in heap dump compression backend Changes: https://git.openjdk.java.net/jdk/pull/3628/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3628&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255661 Stats: 33 lines in 3 files changed: 11 ins; 14 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3628.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3628/head:pull/3628 PR: https://git.openjdk.java.net/jdk/pull/3628 From mseledtsov at openjdk.java.net Tue Apr 27 16:39:36 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 27 Apr 2021 16:39:36 GMT Subject: RFR: 8265690: Use the latest Ubuntu base image version in Docker testing [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 12:37:43 GMT, Aleksey Shipilev wrote: >> Use latest Ubuntu base image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. >> >> Additional testing: >> - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes >> - [x] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass >> - [x] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass > > 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: > > 8265690: Use latest Ubuntu base image version in Docker testing Marked as reviewed by mseledtsov (Committer). Change looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3605 From shade at openjdk.java.net Tue Apr 27 16:39:38 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 27 Apr 2021 16:39:38 GMT Subject: RFR: 8265690: Use the latest Ubuntu base image version in Docker testing [v2] In-Reply-To: References: Message-ID: <0s0o77-nSzfoE66d2SVCmX8CHOE4hW5LQFWRu8PRUuw=.782aba37-55ce-423f-b764-facf6ba9adcb@github.com> On Thu, 22 Apr 2021 12:37:43 GMT, Aleksey Shipilev wrote: >> Use latest Ubuntu base image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. >> >> Additional testing: >> - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes >> - [x] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass >> - [x] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass > > 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: > > 8265690: Use latest Ubuntu base image version in Docker testing Thanks all! ------------- PR: https://git.openjdk.java.net/jdk/pull/3605 From shade at openjdk.java.net Tue Apr 27 16:39:39 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 27 Apr 2021 16:39:39 GMT Subject: Integrated: 8265690: Use the latest Ubuntu base image version in Docker testing In-Reply-To: References: Message-ID: <1wkv-FlH5-2WXbAagdASVbezHouohL2Hab21CXh0b8c=.6da7c163-f7b0-40ad-bdf7-f25dc06c259d@github.com> On Wed, 21 Apr 2021 16:02:55 GMT, Aleksey Shipilev wrote: > Use latest Ubuntu base image to get latest glibc, so that host-built JDK has a higher chance to pass. Current "oraclelinux:7.6" image apparently has glibc 2.27. Please see the bug for more discussion. > > Additional testing: > - [x] `hotspot_containers` tests on Ubuntu 20.04 (glibc 2.31) -- used to fail, now passes > - [x] `hotspot_containers` tests on Debian 9 (glibc 2.24) -- continues to pass > - [x] `hotspot_containers` tests on Centos 7 (glibc 2.17) -- continues to pass This pull request has now been integrated. Changeset: b67b2b16 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/b67b2b16 Stats: 9 lines in 1 file changed: 0 ins; 7 del; 2 mod 8265690: Use the latest Ubuntu base image version in Docker testing Reviewed-by: sgehwolf, iignatyev, mseledtsov ------------- PR: https://git.openjdk.java.net/jdk/pull/3605 From pchilanomate at openjdk.java.net Tue Apr 27 16:53:37 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 27 Apr 2021 16:53:37 GMT Subject: RFR: 8265932: Move safepoint related fields from class Thread to JavaThread [v2] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 20:07:22 GMT, Coleen Phillimore wrote: >> Patricio Chilano Mateo 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 8265932 >> - forgot to remove no_safepoint_verifier() declaration >> - v1 > > Looks good to me! Thanks @coleenp and @dholmes-ora for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3695 From pchilanomate at openjdk.java.net Tue Apr 27 16:56:39 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 27 Apr 2021 16:56:39 GMT Subject: Integrated: 8265932: Move safepoint related fields from class Thread to JavaThread In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 15:01:41 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following change. A left over from?8265453?was moving _poll_data from class Thread to JavaThread. There are also other fields like _no_safepoint_count and _visited_for_critical_count that should be moved. > Tested in mach5 tiers 1-5. Tested it builds ppc, arm and s390. Tested it builds in release, optimized and fastdebug modes. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 5634f206 Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/5634f206 Stats: 239 lines in 30 files changed: 90 ins; 100 del; 49 mod 8265932: Move safepoint related fields from class Thread to JavaThread Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3695 From avoitylov at openjdk.java.net Tue Apr 27 18:22:45 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Tue, 27 Apr 2021 18:22:45 GMT Subject: RFR: JDK-8263396: Atomic::CmpxchgByteUsingInt::set_byte_in_int needs an explicit cast Message-ID: Hi, please review this PR to fix a problem found by SonarCloud. I think it's best to fix it to avoid confusion. As required by the standard, operands of arithmetical operators are implicitly promoted to at least int. Code being fixed assumes int to be at least 32 bits and all implicit promotions are performed to at least 32 bits. It's not a problem with any of the platforms supported by OpenJDK but it won't work correctly on platforms and compilers with 16 bit ints: shift operators will use 16 bit integer and anything shifted to bits 16:31 will be lost. Testing: original case with gcc bug on Arm 32 is not reproduced, pre-submit tests were run. ------------- Commit messages: - add static cast Changes: https://git.openjdk.java.net/jdk/pull/3723/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3723&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263396 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3723.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3723/head:pull/3723 PR: https://git.openjdk.java.net/jdk/pull/3723 From dcubed at openjdk.java.net Tue Apr 27 19:36:19 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 27 Apr 2021 19:36:19 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:08:52 GMT, Daniel D. Daugherty wrote: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Tap, tap, tap... is this thing working? :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From iklam at openjdk.java.net Tue Apr 27 20:50:05 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 27 Apr 2021 20:50:05 GMT Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API In-Reply-To: References: Message-ID: <3aMxpmm2nyW2zPpPcU4ra1Ym6BqF7HryqEp7VDWk3Fc=.6a4cdcbe-3d75-4352-9937-536a632bf269@github.com> On Tue, 27 Apr 2021 12:46:56 GMT, Coleen Phillimore wrote: >> We currently have array_klass() and array_klass_or_null(), where the former can throw exceptions and the latter can not. But they both delegate to: >> >> array_klass_impl(bool or_null, TRAPS) >> >> which combines both the exception-throwing and non-exception-throwing code into one method declared with TRAPS. To make progress with the change of TRAPS to JavaThread (JDK-8252685) we need to separate these code paths into distinct methods. >> >> Testing: tiers 1-3 (in progress) >> >> Thanks, >> David > > src/hotspot/share/oops/klass.hpp line 525: > >> 523: virtual Klass* array_klass_impl(TRAPS); >> 524: virtual Klass* array_klass_or_null_impl(int rank); >> 525: virtual Klass* array_klass_or_null_impl(); > > I think you should make these pure virtual functions (=0) and remove the bodies in klass.cpp. I think now we can get rid of the `array_klass_or_null_impl()` function altogether. Instead, `array_klass_or_null` should be declared as `virtual ... = 0` in `Klass` and implemented by the concrete subclasses. ------------- PR: https://git.openjdk.java.net/jdk/pull/3711 From david.holmes at oracle.com Tue Apr 27 21:05:18 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Apr 2021 07:05:18 +1000 Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API In-Reply-To: <3aMxpmm2nyW2zPpPcU4ra1Ym6BqF7HryqEp7VDWk3Fc=.6a4cdcbe-3d75-4352-9937-536a632bf269@github.com> References: <3aMxpmm2nyW2zPpPcU4ra1Ym6BqF7HryqEp7VDWk3Fc=.6a4cdcbe-3d75-4352-9937-536a632bf269@github.com> Message-ID: <141fe2d6-4983-6464-debf-91c9d5de81c9@oracle.com> On 28/04/2021 6:50 am, Ioi Lam wrote: > On Tue, 27 Apr 2021 12:46:56 GMT, Coleen Phillimore wrote: > >>> We currently have array_klass() and array_klass_or_null(), where the former can throw exceptions and the latter can not. But they both delegate to: >>> >>> array_klass_impl(bool or_null, TRAPS) >>> >>> which combines both the exception-throwing and non-exception-throwing code into one method declared with TRAPS. To make progress with the change of TRAPS to JavaThread (JDK-8252685) we need to separate these code paths into distinct methods. >>> >>> Testing: tiers 1-3 (in progress) >>> >>> Thanks, >>> David >> >> src/hotspot/share/oops/klass.hpp line 525: >> >>> 523: virtual Klass* array_klass_impl(TRAPS); >>> 524: virtual Klass* array_klass_or_null_impl(int rank); >>> 525: virtual Klass* array_klass_or_null_impl(); >> >> I think you should make these pure virtual functions (=0) and remove the bodies in klass.cpp. > > I think now we can get rid of the `array_klass_or_null_impl()` function altogether. Instead, `array_klass_or_null` should be declared as `virtual ... = 0` in `Klass` and implemented by the concrete subclasses. Yes I think you are right - no need to inherit the top-level delegating functions and override the impl functions, when we can just override the top-level functions and delete all the impl functions. I'll give that a whirl. Thanks for looking at this Ioi and Coleen! David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3711 > From dholmes at openjdk.java.net Tue Apr 27 21:23:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Apr 2021 21:23:06 GMT Subject: RFR: JDK-8263396: Atomic::CmpxchgByteUsingInt::set_byte_in_int needs an explicit cast In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 18:15:40 GMT, Aleksei Voitylov wrote: > Hi, > > please review this PR to fix a problem found by SonarCloud. I think it's best to fix it to avoid confusion. > > As required by the standard, operands of arithmetical operators are implicitly promoted to at least int. Code being fixed assumes int to be at least 32 bits and all implicit promotions are performed to at least 32 bits. It's not a problem with any of the platforms supported by OpenJDK but it won't work correctly on platforms and compilers with 16 bit ints: shift operators will use 16 bit integer and anything shifted to bits 16:31 will be lost. > > Testing: original case with gcc bug on Arm 32 is not reproduced, pre-submit tests were run. Hi Aleksei, This seems harmless. But I very much doubt hotspot would build correctly on any system with only 16-bit ints (jint would have to be redefined to a 32-bit type, and then all the types used with jint would need similar adaptation.) Cheers, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3723 From dholmes at openjdk.java.net Tue Apr 27 21:30:26 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Apr 2021 21:30:26 GMT Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API [v2] In-Reply-To: References: Message-ID: > We currently have array_klass() and array_klass_or_null(), where the former can throw exceptions and the latter can not. But they both delegate to: > > array_klass_impl(bool or_null, TRAPS) > > which combines both the exception-throwing and non-exception-throwing code into one method declared with TRAPS. To make progress with the change of TRAPS to JavaThread (JDK-8252685) we need to separate these code paths into distinct methods. > > Testing: tiers 1-3 (in progress) > > Thanks, > David David Holmes 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 - Feedback from Ioi and Coleen: make the base API pure virtual and override those methods directly, getting rid of the impl versions, - 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API ------------- Changes: https://git.openjdk.java.net/jdk/pull/3711/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3711&range=01 Stats: 136 lines in 8 files changed: 65 ins; 51 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/3711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3711/head:pull/3711 PR: https://git.openjdk.java.net/jdk/pull/3711 From iklam at openjdk.java.net Tue Apr 27 21:42:09 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 27 Apr 2021 21:42:09 GMT Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API [v2] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 21:30:26 GMT, David Holmes wrote: >> We currently have array_klass() and array_klass_or_null(), where the former can throw exceptions and the latter can not. But they both delegate to: >> >> array_klass_impl(bool or_null, TRAPS) >> >> which combines both the exception-throwing and non-exception-throwing code into one method declared with TRAPS. To make progress with the change of TRAPS to JavaThread (JDK-8252685) we need to separate these code paths into distinct methods. >> >> Testing: tiers 1-3 (in progress) >> >> Thanks, >> David > > David Holmes 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 > - Feedback from Ioi and Coleen: make the base API pure virtual and override those methods > directly, getting rid of the impl versions, > - 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API LGTM. Just a small nit about comments. src/hotspot/share/oops/instanceKlass.cpp line 1457: > 1455: return NULL; > 1456: } > 1457: // _this will always be set at this point I have a hard time understanding the meaning of the above comment. Maybe it should be removed? (Same foe line 1447). ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3711 From coleenp at openjdk.java.net Tue Apr 27 22:01:18 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 22:01:18 GMT Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API [v2] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 21:30:26 GMT, David Holmes wrote: >> We currently have array_klass() and array_klass_or_null(), where the former can throw exceptions and the latter can not. But they both delegate to: >> >> array_klass_impl(bool or_null, TRAPS) >> >> which combines both the exception-throwing and non-exception-throwing code into one method declared with TRAPS. To make progress with the change of TRAPS to JavaThread (JDK-8252685) we need to separate these code paths into distinct methods. >> >> Testing: tiers 1-3 (in progress) >> >> Thanks, >> David > > David Holmes 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 > - Feedback from Ioi and Coleen: make the base API pure virtual and override those methods > directly, getting rid of the impl versions, > - 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API Looks great. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3711 From dholmes at openjdk.java.net Tue Apr 27 22:45:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Apr 2021 22:45:13 GMT Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API [v2] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 21:37:17 GMT, Ioi Lam wrote: >> David Holmes 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 >> - Feedback from Ioi and Coleen: make the base API pure virtual and override those methods >> directly, getting rid of the impl versions, >> - 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API > > src/hotspot/share/oops/instanceKlass.cpp line 1457: > >> 1455: return NULL; >> 1456: } >> 1457: // _this will always be set at this point > > I have a hard time understanding the meaning of the above comment. Maybe it should be removed? (Same foe line 1447). Until you quoted it I hadn't noticed the underscore on _this. I read it as "this [array_klasses()] will always be set [non-NULL] at this point". I can restructure this as an if-else to make it crystal clear, and avoid the re-read of array_klasses(). ------------- PR: https://git.openjdk.java.net/jdk/pull/3711 From dholmes at openjdk.java.net Tue Apr 27 22:55:27 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Apr 2021 22:55:27 GMT Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API [v3] In-Reply-To: References: Message-ID: > We currently have array_klass() and array_klass_or_null(), where the former can throw exceptions and the latter can not. But they both delegate to: > > array_klass_impl(bool or_null, TRAPS) > > which combines both the exception-throwing and non-exception-throwing code into one method declared with TRAPS. To make progress with the change of TRAPS to JavaThread (JDK-8252685) we need to separate these code paths into distinct methods. > > Testing: tiers 1-3 (in progress) > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Updated comment and simplify code structure in one method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3711/files - new: https://git.openjdk.java.net/jdk/pull/3711/files/80c307c0..d7e7d5a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3711&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3711&range=01-02 Stats: 8 lines in 1 file changed: 3 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3711/head:pull/3711 PR: https://git.openjdk.java.net/jdk/pull/3711 From iklam at openjdk.java.net Tue Apr 27 23:17:10 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 27 Apr 2021 23:17:10 GMT Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API [v3] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 22:55:27 GMT, David Holmes wrote: >> We currently have array_klass() and array_klass_or_null(), where the former can throw exceptions and the latter can not. But they both delegate to: >> >> array_klass_impl(bool or_null, TRAPS) >> >> which combines both the exception-throwing and non-exception-throwing code into one method declared with TRAPS. To make progress with the change of TRAPS to JavaThread (JDK-8252685) we need to separate these code paths into distinct methods. >> >> Testing: tiers 1-3 (in progress) >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment and simplify code structure in one method Latest version looks good. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3711 From cjplummer at openjdk.java.net Tue Apr 27 23:25:23 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 27 Apr 2021 23:25:23 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:08:52 GMT, Daniel D. Daugherty wrote: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. When reviewing this new test, is it worth comparing it with counter based tests that it was based on, or is it best just to view it as a completely new test. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Tue Apr 27 23:55:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 27 Apr 2021 23:55:53 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:08:52 GMT, Daniel D. Daugherty wrote: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. It is not really useful to compare with the counter based M&M tests because this test is exercising/stressing a different API. It could be useful to compare this test to runtime/Thread/SuspendAtExit.java which is a test that was also updated to be time based instead of counter based. I am reworking the remaining existing counter based Thread-SMR tests with a different bug ID (https://bugs.openjdk.java.net/browse/JDK-8266130), but that is a work-in-progress. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dholmes at openjdk.java.net Wed Apr 28 00:14:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 00:14:04 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v4] In-Reply-To: <8vXrcfOBfRr7UkUZ2PQ-6dPy9Ho498YKhoARuCQAOoI=.ea8d6c64-bdfe-4be0-9d7a-6efb7b4a2a66@github.com> References: <8vXrcfOBfRr7UkUZ2PQ-6dPy9Ho498YKhoARuCQAOoI=.ea8d6c64-bdfe-4be0-9d7a-6efb7b4a2a66@github.com> Message-ID: On Fri, 23 Apr 2021 03:02:52 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix bugs Hi, Sorry for the delayed re-review. There are still a bunch of nits with the test logic that I'd like to see addressed. Sorry I should have flagged them earlier. Thanks, David test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 29: > 27: * @summary JVM crashes when two threads encounter the same resolution error > 28: * > 29: * @library /test/lib You don't use the test library test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 33: > 31: * @compile HostNoNestMember.jcod > 32: * > 33: * @run main/othervm TestNestHostErrorWithMultiThread No need for othervm in this test. test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 42: > 40: public static void main(String args[]) { > 41: CountDownLatch latch1 = new CountDownLatch(1); > 42: CountDownLatch latch2 = new CountDownLatch(2); Please rename latch1 as run, and latch2 as started. The names should aid in understanding the logic of the synchronization. test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 45: > 43: > 44: new Thread(new Test(latch1, latch2)).start(); > 45: new Thread(new Test(latch1, latch2)).start(); Nit: you only need a single Runnable instance as it is stateless. The Runnable could even be defined inline rather than as a separate named class. test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 51: > 49: latch2.await(); > 50: latch1.countDown(); > 51: } catch (InterruptedException e) {} Catch block should have: throw new Error("Unexpected interrupt"); test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 70: > 68: latch1.await(); > 69: HostNoNestMember h = new HostNoNestMember(); > 70: h.test(); After the call to test you should have: throw new Error("IllegalAccessError was not thrown as expected"); test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 79: > 77: } > 78: System.out.println("OK - got expected exception: " + expected); > 79: } catch (InterruptedException e) {} Catch block should have: throw new Error("Unexpected interrupt"); ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3392 From whuang at openjdk.java.net Wed Apr 28 06:59:04 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 28 Apr 2021 06:59:04 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v4] In-Reply-To: References: <8vXrcfOBfRr7UkUZ2PQ-6dPy9Ho498YKhoARuCQAOoI=.ea8d6c64-bdfe-4be0-9d7a-6efb7b4a2a66@github.com> Message-ID: On Wed, 28 Apr 2021 00:09:41 GMT, David Holmes wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix bugs > > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 29: > >> 27: * @summary JVM crashes when two threads encounter the same resolution error >> 28: * >> 29: * @library /test/lib > > You don't use the test library Yes. Thank you for your review. > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 33: > >> 31: * @compile HostNoNestMember.jcod >> 32: * >> 33: * @run main/othervm TestNestHostErrorWithMultiThread > > No need for othervm in this test. Sure. I will do that. > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 42: > >> 40: public static void main(String args[]) { >> 41: CountDownLatch latch1 = new CountDownLatch(1); >> 42: CountDownLatch latch2 = new CountDownLatch(2); > > Please rename latch1 as run, and latch2 as started. The names should aid in understanding the logic of the synchronization. Sure. It will make the code more clear. I will do that.Thank you. > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 45: > >> 43: >> 44: new Thread(new Test(latch1, latch2)).start(); >> 45: new Thread(new Test(latch1, latch2)).start(); > > Nit: you only need a single Runnable instance as it is stateless. The Runnable could even be defined inline rather than as a separate named class. It's my fault. I will adjust that. Thank you. > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 70: > >> 68: latch1.await(); >> 69: HostNoNestMember h = new HostNoNestMember(); >> 70: h.test(); > > After the call to test you should have: > > throw new Error("IllegalAccessError was not thrown as expected"); Thank you. I will change that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From whuang at openjdk.java.net Wed Apr 28 07:04:20 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 28 Apr 2021 07:04:20 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v5] In-Reply-To: References: Message-ID: > As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix some bugs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3392/files - new: https://git.openjdk.java.net/jdk/pull/3392/files/b9933eab..7cd04c94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=03-04 Stats: 24 lines in 1 file changed: 7 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3392.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3392/head:pull/3392 PR: https://git.openjdk.java.net/jdk/pull/3392 From ysuenaga at openjdk.java.net Wed Apr 28 07:21:57 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 28 Apr 2021 07:21:57 GMT Subject: RFR: 8266176: -Wmaybe-uninitialized happens in libArrayIndexOutOfBoundsExceptionTest.c Message-ID: <3ucCTjOjzXbLQtaaaZFOMSUX1mADuxWYi_ghk73tFCE=.62910d0d-da37-4bd2-b8cf-62f94393bd06@github.com> We can see some compiler warnings in libArrayIndexOutOfBoundsExceptionTest.c as following on GCC 11. `content` should be initialized. ------------- Commit messages: - 8266176: -Wmaybe-uninitialized happens in libArrayIndexOutOfBoundsExceptionTest.c Changes: https://git.openjdk.java.net/jdk/pull/3744/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3744&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266176 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3744/head:pull/3744 PR: https://git.openjdk.java.net/jdk/pull/3744 From ysuenaga at openjdk.java.net Wed Apr 28 09:54:15 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 28 Apr 2021 09:54:15 GMT Subject: RFR: 8266170: -Wnonnull happens in classLoaderData.inline.hpp Message-ID: We can see compiler warnings in dictionary.cpp as following on GCC 11. Conditions in `guarantee` should be changed. In file included from /home/ysuenaga/git-forked/jdk/src/hotspot/share/utilities/globalDefinitions.hpp:29, from /home/ysuenaga/git-forked/jdk/src/hotspot/share/memory/allocation.hpp:29, from /home/ysuenaga/git-forked/jdk/src/hotspot/share/classfile/classLoaderData.hpp:28, from /home/ysuenaga/git-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:34: In member function 'oop ClassLoaderData::class_loader() const', inlined from 'void Dictionary::verify()' at /home/ysuenaga/git-forked/jdk/src/hotspot/share/classfile/dictionary.cpp:635:3: ------------- Commit messages: - 8266170: -Wnonnull happens in classLoaderData.inline.hpp Changes: https://git.openjdk.java.net/jdk/pull/3753/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3753&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266170 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3753.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3753/head:pull/3753 PR: https://git.openjdk.java.net/jdk/pull/3753 From dholmes at openjdk.java.net Wed Apr 28 12:17:59 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 12:17:59 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v5] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 07:04:20 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix some bugs Looks good. Thanks for your patience here. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3392 From dholmes at openjdk.java.net Wed Apr 28 12:29:02 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 12:29:02 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v5] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 07:04:20 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix some bugs The new test is failing for a reason that is not clear to me yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From dholmes at openjdk.java.net Wed Apr 28 12:40:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 12:40:53 GMT Subject: RFR: 8266170: -Wnonnull happens in classLoaderData.inline.hpp In-Reply-To: References: Message-ID: <4Lv-GMF7te0abM5uPKVeWq1VCgocS7KeFjFMe8N29UI=.851d3935-e912-4db8-949e-87e17b0c15b1@github.com> On Wed, 28 Apr 2021 07:31:26 GMT, Yasumasa Suenaga wrote: > We can see compiler warnings in dictionary.cpp as following on GCC 11. Conditions in `guarantee` should be changed. > > > In file included from /home/ysuenaga/git-forked/jdk/src/hotspot/share/utilities/globalDefinitions.hpp:29, > from /home/ysuenaga/git-forked/jdk/src/hotspot/share/memory/allocation.hpp:29, > from /home/ysuenaga/git-forked/jdk/src/hotspot/share/classfile/classLoaderData.hpp:28, > from /home/ysuenaga/git-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:34: > In member function 'oop ClassLoaderData::class_loader() const', > inlined from 'void Dictionary::verify()' at /home/ysuenaga/git-forked/jdk/src/hotspot/share/classfile/dictionary.cpp:635:3: This change looks good to me. I'll ask Coleen to confirm. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3753 From dholmes at openjdk.java.net Wed Apr 28 12:51:51 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 12:51:51 GMT Subject: RFR: 8266176: -Wmaybe-uninitialized happens in libArrayIndexOutOfBoundsExceptionTest.c In-Reply-To: <3ucCTjOjzXbLQtaaaZFOMSUX1mADuxWYi_ghk73tFCE=.62910d0d-da37-4bd2-b8cf-62f94393bd06@github.com> References: <3ucCTjOjzXbLQtaaaZFOMSUX1mADuxWYi_ghk73tFCE=.62910d0d-da37-4bd2-b8cf-62f94393bd06@github.com> Message-ID: On Wed, 28 Apr 2021 01:23:16 GMT, Yasumasa Suenaga wrote: > We can see some compiler warnings in libArrayIndexOutOfBoundsExceptionTest.c as following on GCC 11. `content` should be initialized. Seems okay. Thanks, David test/hotspot/jtreg/runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/libArrayIndexOutOfBoundsExceptionTest.c line 2: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. Oracle copyright uses a two year format so this should be "2019, 2021," ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3744 From dholmes at openjdk.java.net Wed Apr 28 13:05:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 13:05:50 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> On Wed, 14 Apr 2021 00:08:52 GMT, Daniel D. Daugherty wrote: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. HI Dan, Some minor comments, but to be frank I have no idea what this test is actually doing - sorry. Cheers, David test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 30: > 28: * non-null string for a blocked thread and then makes repeated calls > 29: * to getThreadInfo() and ThreadInfo.getLockOwnerName() until the thread > 30: * has exited. Extra space before has. test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 33: > 31: * @requires vm.jvmti > 32: * @library /test/lib > 33: * @compile getLockOwnerName.java You don't need a @compile statement for the current test file test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 137: > 135: } > 136: > 137: System.exit(run(timeMax, System.out) + exit_delta); jtreg tests don't use System.exit! test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 189: > 187: while (testState != TS_BLOCKER_RUNNING) { > 188: try { > 189: barrierLaunch.wait(0); // wait until it is running Nit: we use wait() rather than wait(0) ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From ysuenaga at openjdk.java.net Wed Apr 28 13:25:09 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 28 Apr 2021 13:25:09 GMT Subject: RFR: 8266176: -Wmaybe-uninitialized happens in libArrayIndexOutOfBoundsExceptionTest.c [v2] In-Reply-To: <3ucCTjOjzXbLQtaaaZFOMSUX1mADuxWYi_ghk73tFCE=.62910d0d-da37-4bd2-b8cf-62f94393bd06@github.com> References: <3ucCTjOjzXbLQtaaaZFOMSUX1mADuxWYi_ghk73tFCE=.62910d0d-da37-4bd2-b8cf-62f94393bd06@github.com> Message-ID: > We can see some compiler warnings in libArrayIndexOutOfBoundsExceptionTest.c as following on GCC 11. `content` should be initialized. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3744/files - new: https://git.openjdk.java.net/jdk/pull/3744/files/d6a34320..cf52e512 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3744&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3744&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3744/head:pull/3744 PR: https://git.openjdk.java.net/jdk/pull/3744 From ysuenaga at openjdk.java.net Wed Apr 28 13:25:10 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 28 Apr 2021 13:25:10 GMT Subject: RFR: 8266176: -Wmaybe-uninitialized happens in libArrayIndexOutOfBoundsExceptionTest.c [v2] In-Reply-To: References: <3ucCTjOjzXbLQtaaaZFOMSUX1mADuxWYi_ghk73tFCE=.62910d0d-da37-4bd2-b8cf-62f94393bd06@github.com> Message-ID: On Wed, 28 Apr 2021 12:43:56 GMT, David Holmes wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > test/hotspot/jtreg/runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/libArrayIndexOutOfBoundsExceptionTest.c line 2: > >> 1: /* >> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. > > Oracle copyright uses a two year format so this should be "2019, 2021," Thanks @dholmes-ora for the review! I updated copyright year in new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/3744 From coleenp at openjdk.java.net Wed Apr 28 13:27:51 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 28 Apr 2021 13:27:51 GMT Subject: RFR: 8266170: -Wnonnull happens in classLoaderData.inline.hpp In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 07:31:26 GMT, Yasumasa Suenaga wrote: > We can see compiler warnings in dictionary.cpp as following on GCC 11. Conditions in `guarantee` should be changed. > > > In file included from /home/ysuenaga/git-forked/jdk/src/hotspot/share/utilities/globalDefinitions.hpp:29, > from /home/ysuenaga/git-forked/jdk/src/hotspot/share/memory/allocation.hpp:29, > from /home/ysuenaga/git-forked/jdk/src/hotspot/share/classfile/classLoaderData.hpp:28, > from /home/ysuenaga/git-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:34: > In member function 'oop ClassLoaderData::class_loader() const', > inlined from 'void Dictionary::verify()' at /home/ysuenaga/git-forked/jdk/src/hotspot/share/classfile/dictionary.cpp:635:3: Thank you for fixing this! src/hotspot/share/classfile/dictionary.cpp line 636: > 634: // boostrap loader > 635: guarantee(cld != NULL && > 636: (cld->the_null_class_loader_data() || cld->class_loader()->is_instance()), This is right. The CLD can never be null here because we create a dictionary for each CLD and link back the CLD. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3753 From ysuenaga at openjdk.java.net Wed Apr 28 13:34:50 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 28 Apr 2021 13:34:50 GMT Subject: RFR: 8266170: -Wnonnull happens in classLoaderData.inline.hpp In-Reply-To: <4Lv-GMF7te0abM5uPKVeWq1VCgocS7KeFjFMe8N29UI=.851d3935-e912-4db8-949e-87e17b0c15b1@github.com> References: <4Lv-GMF7te0abM5uPKVeWq1VCgocS7KeFjFMe8N29UI=.851d3935-e912-4db8-949e-87e17b0c15b1@github.com> Message-ID: On Wed, 28 Apr 2021 12:37:57 GMT, David Holmes wrote: >> We can see compiler warnings in dictionary.cpp as following on GCC 11. Conditions in `guarantee` should be changed. >> >> >> In file included from /home/ysuenaga/git-forked/jdk/src/hotspot/share/utilities/globalDefinitions.hpp:29, >> from /home/ysuenaga/git-forked/jdk/src/hotspot/share/memory/allocation.hpp:29, >> from /home/ysuenaga/git-forked/jdk/src/hotspot/share/classfile/classLoaderData.hpp:28, >> from /home/ysuenaga/git-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:34: >> In member function 'oop ClassLoaderData::class_loader() const', >> inlined from 'void Dictionary::verify()' at /home/ysuenaga/git-forked/jdk/src/hotspot/share/classfile/dictionary.cpp:635:3: > > This change looks good to me. > > I'll ask Coleen to confirm. > > Thanks, > David Thanks @dholmes-ora and @coleenp for your review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3753 From pchilanomate at openjdk.java.net Wed Apr 28 13:49:01 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 28 Apr 2021 13:49:01 GMT Subject: RFR: 8265933: Move Java monitor related fields from class Thread to JavaThread Message-ID: Hi, Please review the following change. Fields in class Thread related to Java object monitors like _current_pending_monitor, _current_pending_monitor_is_from_java, _current_waiting_monitor and _Stalled should be moved to the JavaThread class. Members _OnTrap and _TypeTag were grouped together with _Stalled but are not used so I removed them. It seems they were part of the ObjectMonitor implementation at some point but I couldn't find how they were used. Tested in mach5 tier1-2. Thanks, Patricio ------------- Commit messages: - fix serviceability agent - v1 Changes: https://git.openjdk.java.net/jdk/pull/3722/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3722&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265933 Stats: 89 lines in 4 files changed: 36 ins; 43 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3722/head:pull/3722 PR: https://git.openjdk.java.net/jdk/pull/3722 From hseigel at openjdk.java.net Wed Apr 28 14:09:06 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 28 Apr 2021 14:09:06 GMT Subject: RFR: 8266087: Move 'buffer' declaration in get_user_name_slow() inside of linux specific code Message-ID: Please review this very small fix for JDK-8266087. The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows. Thanks, Harold ------------- Commit messages: - 8266087: Move 'buffer' declaration in get_user_name_slow() inside of linux specific code Changes: https://git.openjdk.java.net/jdk/pull/3761/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3761&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266087 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3761.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3761/head:pull/3761 PR: https://git.openjdk.java.net/jdk/pull/3761 From rehn at openjdk.java.net Wed Apr 28 14:08:53 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 28 Apr 2021 14:08:53 GMT Subject: RFR: 8265933: Move Java monitor related fields from class Thread to JavaThread In-Reply-To: References: Message-ID: <-m0TGrIg_eNe8NGjlnv_wOME3uQGmFyr-EQGWbJnWdo=.d5c39a17-de42-494d-b861-c32785940e5c@github.com> On Tue, 27 Apr 2021 18:08:19 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following change. Fields in class Thread related to Java object monitors like _current_pending_monitor, _current_pending_monitor_is_from_java, _current_waiting_monitor and _Stalled should be moved to the JavaThread class. Members _OnTrap and _TypeTag were grouped together with _Stalled but are not used so I removed them. It seems they were part of the ObjectMonitor implementation at some point but I couldn't find how they were used. > Tested in mach5 tier1-2. > > Thanks, > Patricio Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3722 From zgu at openjdk.java.net Wed Apr 28 14:26:53 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 28 Apr 2021 14:26:53 GMT Subject: RFR: 8266087: Move 'buffer' declaration in get_user_name_slow() inside of linux specific code In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 14:01:14 GMT, Harold Seigel wrote: > Please review this very small fix for JDK-8266087. The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows. > > Thanks, Harold Looks good and trivial ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3761 From dcubed at openjdk.java.net Wed Apr 28 14:46:50 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 28 Apr 2021 14:46:50 GMT Subject: RFR: 8266087: Move 'buffer' declaration in get_user_name_slow() inside of linux specific code In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 14:01:14 GMT, Harold Seigel wrote: > Please review this very small fix for JDK-8266087. The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows. > > Thanks, Harold Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3761 From hseigel at openjdk.java.net Wed Apr 28 14:53:51 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 28 Apr 2021 14:53:51 GMT Subject: RFR: 8266087: Move 'buffer' declaration in get_user_name_slow() inside of linux specific code In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 14:01:14 GMT, Harold Seigel wrote: > Please review this very small fix for JDK-8266087. The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows. > > Thanks, Harold Thanks Zhengyu and Dan for reviewing this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3761 From hseigel at openjdk.java.net Wed Apr 28 14:53:52 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 28 Apr 2021 14:53:52 GMT Subject: Integrated: 8266087: Move 'buffer' declaration in get_user_name_slow() inside of linux specific code In-Reply-To: References: Message-ID: <6XmXfjrlmXlT37idoQbOQnk6dUgXjk6c2Mg0rVoVYrA=.a59f34c1-8000-4b49-b0bc-5246060d727f@github.com> On Wed, 28 Apr 2021 14:01:14 GMT, Harold Seigel wrote: > Please review this very small fix for JDK-8266087. The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows. > > Thanks, Harold This pull request has now been integrated. Changeset: f40bf1d2 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/f40bf1d24010e3bd9252cef790e9f3039376fb08 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8266087: Move 'buffer' declaration in get_user_name_slow() inside of linux specific code Reviewed-by: zgu, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3761 From redestad at openjdk.java.net Wed Apr 28 14:56:13 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Apr 2021 14:56:13 GMT Subject: RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters Message-ID: This patch refactors AdapterHandlerLibrary initialization so that we can initialize a handful of commonly used adapters early during bootstrap, and avoid taking the AdapterHandlerLibrary_lock when looking up these adapters. Since the 5 most common adapters plus the abstract adapter constitutes roughly 60% of the method shapes loaded and linked on a Hello World, this means a relatively significant startup optimization (~2M insns on Hello World); most of the win is in lookup code that will be a significant part of the cost of class loading even when no adapters need to be generated. This enhancement partially recuperates the regression reported in https://bugs.openjdk.java.net/browse/JDK-8265523 ------------- Commit messages: - Use signature constants - Make sure all adapters are in the table to avoid duplicates, reduce work done inside lock - Type typo - Fix ResourceMark, remove pointer from adapter handler name - Various cleanups - Various improvements, fix PrintAdapterHandlers/VerifyAdapterCalls/-Sharing - Merge branch 'master' into adapter_init - Initialize AdapterHandlerLibrary and the most common handlers during bootstrap Changes: https://git.openjdk.java.net/jdk/pull/3706/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3706&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266015 Stats: 324 lines in 2 files changed: 184 ins; 46 del; 94 mod Patch: https://git.openjdk.java.net/jdk/pull/3706.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3706/head:pull/3706 PR: https://git.openjdk.java.net/jdk/pull/3706 From redestad at openjdk.java.net Wed Apr 28 14:56:13 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Apr 2021 14:56:13 GMT Subject: RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 00:27:56 GMT, Claes Redestad wrote: > This patch refactors AdapterHandlerLibrary initialization so that we can initialize a handful of commonly used adapters early during bootstrap, and avoid taking the AdapterHandlerLibrary_lock when looking up these adapters. > > Since the 5 most common adapters plus the abstract adapter constitutes roughly 60% of the method shapes loaded and linked on a Hello World, this means a relatively significant startup optimization (~2M insns on Hello World); most of the win is in lookup code that will be a significant part of the cost of class loading even when no adapters need to be generated. > > This enhancement partially recuperates the regression reported in https://bugs.openjdk.java.net/browse/JDK-8265523 To avoid making this code more complex, and enable splitting apart `get_adapter`, this patch simplifies the output for the develop flag `PrintAdapterHandlers` somewhat. Before this would arbitrarily print the signature of the method that happen to cause the adapter to be generated. Since adapters for methods with the same basic type arguments are shared it makes more sense to distill to BasicType strings. Before: AHE at 0x00007efc503007a0: 0xbaabbaa0 i2c: 0x00007efc399484e0 c2i: 0x00007efc399485e2 c2iUV: 0x00007efc399485a8 c2iNCI: 0x00007efc3994861f i2c argument handler #246 for: static ([Ljava/lang/Object;IILjava/util/Comparator;[Ljava/lang/Object;II)V 0xbaabbaa0 (614 bytes generated) c2i argument handler starts at 0x7efc399485e2 After: AHE at 0x00007fc28c2f6850: 0x0baabbaa i2c: 0x00007fc27570d460 c2i: 0x00007fc27570d562 c2iUV: 0x00007fc27570d528 c2iNCI: 0x00007fc27570d59f i2c argument handler #244 for: LIILLII 0x0baabbaa (614 bytes generated) c2i argument handler starts at 0x7fc27570d562 ------------- PR: https://git.openjdk.java.net/jdk/pull/3706 From dcubed at openjdk.java.net Wed Apr 28 16:23:57 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 28 Apr 2021 16:23:57 GMT Subject: RFR: 8265933: Move Java monitor related fields from class Thread to JavaThread In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 18:08:19 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following change. Fields in class Thread related to Java object monitors like _current_pending_monitor, _current_pending_monitor_is_from_java, _current_waiting_monitor and _Stalled should be moved to the JavaThread class. Members _OnTrap and _TypeTag were grouped together with _Stalled but are not used so I removed them. It seems they were part of the ObjectMonitor implementation at some point but I couldn't find how they were used. > Tested in mach5 tier1-2. > > Thanks, > Patricio Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3722 From ccheung at openjdk.java.net Wed Apr 28 17:53:05 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 28 Apr 2021 17:53:05 GMT Subject: RFR: 8264472: Add a test group for running CDS tests with -XX:+VerifySharedSpaces Message-ID: Add a new test group `hotspot_cds_verify_shared_spaces` for running some CDS tests with the `-XX:+VerifySharedSpaces` option. Testing: hs-tier4. ------------- Commit messages: - 8264472: Add a test group for running CDS tests with -XX:+VerifySharedSpaces Changes: https://git.openjdk.java.net/jdk/pull/3771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3771&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264472 Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3771/head:pull/3771 PR: https://git.openjdk.java.net/jdk/pull/3771 From iklam at openjdk.java.net Wed Apr 28 17:57:55 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 28 Apr 2021 17:57:55 GMT Subject: RFR: 8264472: Add a test group for running CDS tests with -XX:+VerifySharedSpaces In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 17:38:17 GMT, Calvin Cheung wrote: > Add a new test group `hotspot_cds_verify_shared_spaces` for running some CDS tests with the `-XX:+VerifySharedSpaces` option. > > Testing: hs-tier4. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3771 From mseledtsov at openjdk.java.net Wed Apr 28 18:02:52 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Wed, 28 Apr 2021 18:02:52 GMT Subject: RFR: 8264472: Add a test group for running CDS tests with -XX:+VerifySharedSpaces In-Reply-To: References: Message-ID: <1bvDo0trbPeoOhzblouvG0XqIGqQAWEjjWKsKhE4o6M=.3f7ca912-d0f6-4cc5-8384-cddaf126d9b5@github.com> On Wed, 28 Apr 2021 17:38:17 GMT, Calvin Cheung wrote: > Add a new test group `hotspot_cds_verify_shared_spaces` for running some CDS tests with the `-XX:+VerifySharedSpaces` option. > > Testing: hs-tier4. Good idea. Changes look good to me. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk/pull/3771 From ccheung at openjdk.java.net Wed Apr 28 18:09:01 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 28 Apr 2021 18:09:01 GMT Subject: RFR: 8264472: Add a test group for running CDS tests with -XX:+VerifySharedSpaces In-Reply-To: References: Message-ID: <4sDq9fYxBjWfamwNXUzjOdv55-gWYLIqlFzyQA5j818=.2d9184dd-f068-4bb3-8fdf-9fbce815766e@github.com> On Wed, 28 Apr 2021 17:54:34 GMT, Ioi Lam wrote: >> Add a new test group `hotspot_cds_verify_shared_spaces` for running some CDS tests with the `-XX:+VerifySharedSpaces` option. >> >> Testing: hs-tier4. > > LGTM @iklam, @mseledts, Thanks for the quick review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3771 From ccheung at openjdk.java.net Wed Apr 28 18:23:51 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 28 Apr 2021 18:23:51 GMT Subject: Integrated: 8264472: Add a test group for running CDS tests with -XX:+VerifySharedSpaces In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 17:38:17 GMT, Calvin Cheung wrote: > Add a new test group `hotspot_cds_verify_shared_spaces` for running some CDS tests with the `-XX:+VerifySharedSpaces` option. > > Testing: hs-tier4. This pull request has now been integrated. Changeset: d12e01a5 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/d12e01a5cd966809f9a7721b42f8e2b9e3e0f67e Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod 8264472: Add a test group for running CDS tests with -XX:+VerifySharedSpaces Reviewed-by: iklam, mseledtsov ------------- PR: https://git.openjdk.java.net/jdk/pull/3771 From dholmes at openjdk.java.net Wed Apr 28 20:25:54 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 20:25:54 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v5] In-Reply-To: References: Message-ID: <0MLIgTj_K99D27FlPQyKJ1VglX4wNWFRDjd0CS-XmM0=.168b02ac-c2e1-451d-801f-e85d72fff543@github.com> On Wed, 28 Apr 2021 07:04:20 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix some bugs I was unable to reproduce the test failure locally. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From dholmes at openjdk.java.net Wed Apr 28 20:55:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 20:55:52 GMT Subject: Integrated: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 04:47:32 GMT, David Holmes wrote: > We currently have array_klass() and array_klass_or_null(), where the former can throw exceptions and the latter can not. But they both delegate to: > > array_klass_impl(bool or_null, TRAPS) > > which combines both the exception-throwing and non-exception-throwing code into one method declared with TRAPS. To make progress with the change of TRAPS to JavaThread (JDK-8252685) we need to separate these code paths into distinct methods. > > Testing: tiers 1-3 (in progress) > > Thanks, > David This pull request has now been integrated. Changeset: 23180f84 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/23180f848f068434d018b741db6f34cd4b6da55d Stats: 134 lines in 8 files changed: 63 ins; 49 del; 22 mod 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API Reviewed-by: coleenp, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3711 From coleenp at openjdk.java.net Wed Apr 28 20:58:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 28 Apr 2021 20:58:57 GMT Subject: RFR: 8265933: Move Java monitor related fields from class Thread to JavaThread In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 18:08:19 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following change. Fields in class Thread related to Java object monitors like _current_pending_monitor, _current_pending_monitor_is_from_java, _current_waiting_monitor and _Stalled should be moved to the JavaThread class. Members _OnTrap and _TypeTag were grouped together with _Stalled but are not used so I removed them. It seems they were part of the ObjectMonitor implementation at some point but I couldn't find how they were used. > Tested in mach5 tier1-2. > > Thanks, > Patricio Marked as reviewed by coleenp (Reviewer). src/hotspot/share/runtime/thread.hpp line 666: > 664: > 665: public: > 666: ParkEvent * volatile _ParkEvent; // for Object monitors, JVMTI raw monitors, So are jvmti raw monitors not required to be taken on a Java Thread? ------------- PR: https://git.openjdk.java.net/jdk/pull/3722 From dholmes at openjdk.java.net Wed Apr 28 21:15:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 21:15:52 GMT Subject: RFR: 8265933: Move Java monitor related fields from class Thread to JavaThread In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 18:08:19 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following change. Fields in class Thread related to Java object monitors like _current_pending_monitor, _current_pending_monitor_is_from_java, _current_waiting_monitor and _Stalled should be moved to the JavaThread class. Members _OnTrap and _TypeTag were grouped together with _Stalled but are not used so I removed them. It seems they were part of the ObjectMonitor implementation at some point but I couldn't find how they were used. > Tested in mach5 tier1-2. > > Thanks, > Patricio Hi Patricio, Changes look good! The two unused fields appear to have never been used. They were added, but not used, in JDK 6.0b59 (JDK-5030359). I can only assume they were part of experimental code that never made it into the product. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3722 From pchilanomate at openjdk.java.net Wed Apr 28 22:03:52 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 28 Apr 2021 22:03:52 GMT Subject: RFR: 8265933: Move Java monitor related fields from class Thread to JavaThread In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:58:02 GMT, Coleen Phillimore wrote: >> Hi, >> >> Please review the following change. Fields in class Thread related to Java object monitors like _current_pending_monitor, _current_pending_monitor_is_from_java, _current_waiting_monitor and _Stalled should be moved to the JavaThread class. Members _OnTrap and _TypeTag were grouped together with _Stalled but are not used so I removed them. It seems they were part of the ObjectMonitor implementation at some point but I couldn't find how they were used. >> Tested in mach5 tier1-2. >> >> Thanks, >> Patricio > > src/hotspot/share/runtime/thread.hpp line 666: > >> 664: >> 665: public: >> 666: ParkEvent * volatile _ParkEvent; // for Object monitors, JVMTI raw monitors, > > So are jvmti raw monitors not required to be taken on a Java Thread? Hi Coleen, > So are jvmti raw monitors not required to be taken on a Java Thread? I thought they were, but JvmtiRawMonitor::raw_enter() has a conditional that checks whether the thread is a JavaThread or not. I looked at the generated jvmti_RawMonitorEnter() method and don't see a straightforward return for non-JavaThreads. They are rather filtered inside a conditional: if (Threads::number_of_threads() == 0) { transition = false; } else { this_thread = Thread::current_or_null(); transition = ((this_thread != NULL) && !this_thread->is_Named_thread()); } if (transition) { if (!this_thread->is_Java_thread()) { return JVMTI_ERROR_UNATTACHED_THREAD; } ... // error checking err = jvmti_env->RawMonitorEnter(rmonitor); } else { ... // error checking err = jvmti_env->RawMonitorEnter(rmonitor); } If this_thread is NULL or a NamedThread I would have expected a plain return, like other jvmti methods do (e.g. jvmti_GetBytecodes): Thread* this_thread = Thread::current_or_null(); if (this_thread == NULL || !this_thread->is_Java_thread()) { return JVMTI_ERROR_UNATTACHED_THREAD; } Since the this_thread == NULL case should crash before getting to raw_enter() (unless we are also in the case where Threads::number_of_threads() == 0 in which case we just append the monitor to a list of pending monitors and return), that can't be the reason why raw_enter() receives Thread* instead of JavaThread*. So that leaves the NamedThread case then. I would guess that case is for the VMThread (we might call here when posting jvmti events?). ------------- PR: https://git.openjdk.java.net/jdk/pull/3722 From iklam at openjdk.java.net Thu Apr 29 00:49:00 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 29 Apr 2021 00:49:00 GMT Subject: RFR: 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used Message-ID: When CDS tries to load sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo from the classlist, the VM has already finished the "early" bootup phase. To load this class, the module system tries to create an instance of jdk.internal.module.SystemModuleFinders$SystemModuleReader and store that into the ArchivedBootLayer. However, the SystemModuleReader class is also not yet loaded, so the VM loads it on demand. As a result, SystemModuleReader is treated as a "non-early class". The problem is now ArchivedBootLayer refers to a non-early class. At runtime, if JVMTI ClassLoadHook is enabled, HeapShared will refuse to load ArchivedBootLayer from the archived heap. The reason is explained by this in heapShared.cpp: // Note: if a ArchivedKlassSubGraphInfoRecord contains non-early classes, and JVMTI // ClassFileLoadHook is enabled, it's possible for this class to be dynamically replaced. In // this case, we will not load the ArchivedKlassSubGraphInfoRecord and will clear its roots. However, this doesn't make sense for ArchivedBootLayer -- it's loaded in the early phase at runtime, so any classes referenced by ArchivedBootLayer will also be loaded in the early phase. This means JVMTI ClassLoadHook cannot replace SystemModuleReader. Hence, the fix is simple -- for any classes referenced by the 3 "full-module-graph" subgraphs, we always treat them as "early" classes, regardless of when they are loaded during dump time. // Entry fields for subgraphs archived in the open archive heap region (full module graph). static ArchivableStaticFieldInfo fmg_open_archive_subgraph_entry_fields[] = { {"jdk/internal/loader/ArchivedClassLoaders", "archivedClassLoaders"}, {"jdk/internal/module/ArchivedBootLayer", "archivedBootLayer"}, {"java/lang/Module$ArchivedData", "archivedData"}, }; The validate the fix, I modified the test case to always load CLDRLocaleDataMetaInfo during dump time. The test failed without the fix and passed with the fix. ------------- Commit messages: - 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used Changes: https://git.openjdk.java.net/jdk/pull/3780/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3780&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262376 Stats: 19 lines in 2 files changed: 12 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3780.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3780/head:pull/3780 PR: https://git.openjdk.java.net/jdk/pull/3780 From ysuenaga at openjdk.java.net Thu Apr 29 01:07:50 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 29 Apr 2021 01:07:50 GMT Subject: Integrated: 8266170: -Wnonnull happens in classLoaderData.inline.hpp In-Reply-To: References: Message-ID: <248kW8NI50Z0p3o8PkK4OYKGpRk7A5AutcVwU1mXSYs=.ffbe40ac-6077-4f63-9b5a-4cd1ff4bc8ff@github.com> On Wed, 28 Apr 2021 07:31:26 GMT, Yasumasa Suenaga wrote: > We can see compiler warnings in dictionary.cpp as following on GCC 11. Conditions in `guarantee` should be changed. > > > In file included from /home/ysuenaga/git-forked/jdk/src/hotspot/share/utilities/globalDefinitions.hpp:29, > from /home/ysuenaga/git-forked/jdk/src/hotspot/share/memory/allocation.hpp:29, > from /home/ysuenaga/git-forked/jdk/src/hotspot/share/classfile/classLoaderData.hpp:28, > from /home/ysuenaga/git-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:34: > In member function 'oop ClassLoaderData::class_loader() const', > inlined from 'void Dictionary::verify()' at /home/ysuenaga/git-forked/jdk/src/hotspot/share/classfile/dictionary.cpp:635:3: This pull request has now been integrated. Changeset: a1c942c0 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/a1c942c02b65a7fc2a837d2bb43fa134dadcad11 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8266170: -Wnonnull happens in classLoaderData.inline.hpp Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3753 From dholmes at openjdk.java.net Thu Apr 29 01:44:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 29 Apr 2021 01:44:55 GMT Subject: RFR: 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 00:32:51 GMT, Ioi Lam wrote: > When CDS tries to load sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo from the classlist, the VM has already finished the "early" bootup phase. To load this class, the module system tries to create an instance of jdk.internal.module.SystemModuleFinders$SystemModuleReader and store that into the ArchivedBootLayer. However, the SystemModuleReader class is also not yet loaded, so the VM loads it on demand. As a result, SystemModuleReader is treated as a "non-early class". > > The problem is now ArchivedBootLayer refers to a non-early class. At runtime, if JVMTI ClassLoadHook is enabled, HeapShared will refuse to load ArchivedBootLayer from the archived heap. The reason is explained by this in heapShared.cpp: > > > // Note: if a ArchivedKlassSubGraphInfoRecord contains non-early classes, and JVMTI > // ClassFileLoadHook is enabled, it's possible for this class to be dynamically replaced. In > // this case, we will not load the ArchivedKlassSubGraphInfoRecord and will clear its roots. > > > However, this doesn't make sense for ArchivedBootLayer -- it's loaded in the early phase at runtime, so any classes referenced by ArchivedBootLayer will also be loaded in the early phase. This means JVMTI ClassLoadHook cannot replace SystemModuleReader. > > Hence, the fix is simple -- for any classes referenced by the 3 "full-module-graph" subgraphs, we always treat them as "early" classes, regardless of when they are loaded during dump time. > > > // Entry fields for subgraphs archived in the open archive heap region (full module graph). > static ArchivableStaticFieldInfo fmg_open_archive_subgraph_entry_fields[] = { > {"jdk/internal/loader/ArchivedClassLoaders", "archivedClassLoaders"}, > {"jdk/internal/module/ArchivedBootLayer", "archivedBootLayer"}, > {"java/lang/Module$ArchivedData", "archivedData"}, > }; > > > The validate the fix, I modified the test case to always load CLDRLocaleDataMetaInfo during dump time. The test failed without the fix and passed with the fix. Hi Ioi, Based on your detailed description the fix seems quite reasonable. Does this mean that when using CDS some classes are not subject to the application of the JVM TI ClassFileLoadHook? And if so, is that constraint documented somewhere? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3780 From whuang at openjdk.java.net Thu Apr 29 01:56:53 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 29 Apr 2021 01:56:53 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v5] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 12:26:05 GMT, David Holmes wrote: > The new test is failing for a reason that is not clear to me yet. I will run regression and check this thing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From minqi at openjdk.java.net Thu Apr 29 02:55:50 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 29 Apr 2021 02:55:50 GMT Subject: RFR: 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 00:32:51 GMT, Ioi Lam wrote: > When CDS tries to load sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo from the classlist, the VM has already finished the "early" bootup phase. To load this class, the module system tries to create an instance of jdk.internal.module.SystemModuleFinders$SystemModuleReader and store that into the ArchivedBootLayer. However, the SystemModuleReader class is also not yet loaded, so the VM loads it on demand. As a result, SystemModuleReader is treated as a "non-early class". > > The problem is now ArchivedBootLayer refers to a non-early class. At runtime, if JVMTI ClassLoadHook is enabled, HeapShared will refuse to load ArchivedBootLayer from the archived heap. The reason is explained by this in heapShared.cpp: > > > // Note: if a ArchivedKlassSubGraphInfoRecord contains non-early classes, and JVMTI > // ClassFileLoadHook is enabled, it's possible for this class to be dynamically replaced. In > // this case, we will not load the ArchivedKlassSubGraphInfoRecord and will clear its roots. > > > However, this doesn't make sense for ArchivedBootLayer -- it's loaded in the early phase at runtime, so any classes referenced by ArchivedBootLayer will also be loaded in the early phase. This means JVMTI ClassLoadHook cannot replace SystemModuleReader. > > Hence, the fix is simple -- for any classes referenced by the 3 "full-module-graph" subgraphs, we always treat them as "early" classes, regardless of when they are loaded during dump time. > > > // Entry fields for subgraphs archived in the open archive heap region (full module graph). > static ArchivableStaticFieldInfo fmg_open_archive_subgraph_entry_fields[] = { > {"jdk/internal/loader/ArchivedClassLoaders", "archivedClassLoaders"}, > {"jdk/internal/module/ArchivedBootLayer", "archivedBootLayer"}, > {"java/lang/Module$ArchivedData", "archivedData"}, > }; > > > The validate the fix, I modified the test case to always load CLDRLocaleDataMetaInfo during dump time. The test failed without the fix and passed with the fix. LGTM ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3780 From iklam at openjdk.java.net Thu Apr 29 04:15:51 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 29 Apr 2021 04:15:51 GMT Subject: RFR: 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 01:41:34 GMT, David Holmes wrote: > Does this mean that when using CDS some classes are not subject to the application of the JVM TI ClassFileLoadHook? And if so, is that constraint documented somewhere? Hi David, thanks for the review. CDS tries to be transparent w.r.t. ClassFileLoadHook: - If JVMTI "early" ClassFileLoadHooks are enabled, CDS is disabled. - If only JVMTI "non-early" ClassFileLoadHooks are enabled, they will get all the class loading events that happen after the VM has finished the early phase. (This is the same whether CDS is enabled or not). Since the module graph is built during the early phase, a "non-early" ClassFileLoadHook cannot expect to get the loading events for the classes that were loaded in order to build the module graph. The exact set of such classes depend on the implementation of the module system, so it could change between JDK versions. This change only affects two internal classes - sun.net.www.protocol.jrt.Handler and jdk.internal.module.SystemModuleFinders$SystemModuleReader, so I think the impact is minimal. ------------- PR: https://git.openjdk.java.net/jdk/pull/3780 From iklam at openjdk.java.net Thu Apr 29 04:51:58 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 29 Apr 2021 04:51:58 GMT Subject: RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters In-Reply-To: References: Message-ID: <5QOjFYyn9l3Hav1Ck1kccCQhp25mlHNakefQ4offRDI=.c0b9c446-318f-440a-bf6c-f5c453e06233@github.com> On Tue, 27 Apr 2021 00:27:56 GMT, Claes Redestad wrote: > This patch refactors AdapterHandlerLibrary initialization so that we can initialize a handful of commonly used adapters early during bootstrap, and avoid taking the AdapterHandlerLibrary_lock when looking up these adapters. > > Since the 5 most common adapters plus the abstract adapter constitutes roughly 60% of the method shapes loaded and linked on a Hello World, this means a relatively significant startup optimization (~2M insns on Hello World); most of the win is in lookup code that will be a significant part of the cost of class loading even when no adapters need to be generated. > > This enhancement partially recuperates the regression reported in https://bugs.openjdk.java.net/browse/JDK-8265523 Looks good overall, but I think we should avoid changing the `return NULL` to `fatal()`. Also note to other reviewers: when looking at the "Files changed", add `&w=1` to the URL so GitHub will ignore whitespace changes. src/hotspot/share/runtime/sharedRuntime.cpp line 2396: > 2394: int value = 0; > 2395: for (int byte = 0; sig_index < total_args_passed && byte < _basic_types_per_int; byte++) { > 2396: int bt = adapter_encoding(sig_bt[sig_index++]); Why is the above changed? Is it for performance? It seems unrelated to this PR. src/hotspot/share/runtime/sharedRuntime.cpp line 2883: > 2881: NOT_PRODUCT(int insts_size = buffer.insts_size()); > 2882: if (new_adapter == NULL) { > 2883: fatal("No memory to create adapter"); This used to be `return NULL;`, and the JVM is supposed to continue execution (but the linking of the current class will get a VirtualMachineError. I think we should keep the old behavior. ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3706 From alanb at openjdk.java.net Thu Apr 29 06:00:52 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 29 Apr 2021 06:00:52 GMT Subject: RFR: 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 04:13:05 GMT, Ioi Lam wrote: > Does this mean that when using CDS some classes are not subject to the application of the JVM TI ClassFileLoadHook? And if so, is that constraint documented somewhere? At one point, enabling the can_generate_all_class_hook_events capability in the onload phase would disable CDS but maybe that has changed? In any case, the only place in the specs where it touches on this is in the CFLH event itself where it has a sentence about not generating the event for some classes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3780 From david.holmes at oracle.com Thu Apr 29 07:52:04 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Apr 2021 17:52:04 +1000 Subject: RFR: 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used In-Reply-To: References: Message-ID: <497f1cc1-aca8-4f94-679f-33ebb655a547@oracle.com> On 29/04/2021 2:15 pm, Ioi Lam wrote: > On Thu, 29 Apr 2021 01:41:34 GMT, David Holmes wrote: > >> Does this mean that when using CDS some classes are not subject to the application of the JVM TI ClassFileLoadHook? And if so, is that constraint documented somewhere? > > Hi David, thanks for the review. > > CDS tries to be transparent w.r.t. ClassFileLoadHook: > > - If JVMTI "early" ClassFileLoadHooks are enabled, CDS is disabled. > - If only JVMTI "non-early" ClassFileLoadHooks are enabled, they will get all the class loading events that happen after the VM has finished the early phase. (This is the same whether CDS is enabled or not). > > Since the module graph is built during the early phase, a "non-early" ClassFileLoadHook cannot expect to get the loading events for the classes that were loaded in order to build the module graph. > > The exact set of such classes depend on the implementation of the module system, so it could change between JDK versions. This change only affects two internal classes - sun.net.www.protocol.jrt.Handler and jdk.internal.module.SystemModuleFinders$SystemModuleReader, so I think the impact is minimal. Thanks for clarifying, I had forgotten that the module system had introduced two phases for the CFLH. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3780 > From ysuenaga at openjdk.java.net Thu Apr 29 08:02:52 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 29 Apr 2021 08:02:52 GMT Subject: Integrated: 8266176: -Wmaybe-uninitialized happens in libArrayIndexOutOfBoundsExceptionTest.c In-Reply-To: <3ucCTjOjzXbLQtaaaZFOMSUX1mADuxWYi_ghk73tFCE=.62910d0d-da37-4bd2-b8cf-62f94393bd06@github.com> References: <3ucCTjOjzXbLQtaaaZFOMSUX1mADuxWYi_ghk73tFCE=.62910d0d-da37-4bd2-b8cf-62f94393bd06@github.com> Message-ID: On Wed, 28 Apr 2021 01:23:16 GMT, Yasumasa Suenaga wrote: > We can see some compiler warnings in libArrayIndexOutOfBoundsExceptionTest.c as following on GCC 11. `content` should be initialized. This pull request has now been integrated. Changeset: 39abac98 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/39abac98f9803897e40c32d5bcb35bd25c348d2a Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8266176: -Wmaybe-uninitialized happens in libArrayIndexOutOfBoundsExceptionTest.c Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3744 From redestad at openjdk.java.net Thu Apr 29 14:47:15 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 29 Apr 2021 14:47:15 GMT Subject: RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters [v2] In-Reply-To: References: Message-ID: > This patch refactors AdapterHandlerLibrary initialization so that we can initialize a handful of commonly used adapters early during bootstrap, and avoid taking the AdapterHandlerLibrary_lock when looking up these adapters. > > Since the 5 most common adapters plus the abstract adapter constitutes roughly 60% of the method shapes loaded and linked on a Hello World, this means a relatively significant startup optimization (~2M insns on Hello World); most of the win is in lookup code that will be a significant part of the cost of class loading even when no adapters need to be generated. > > This enhancement partially recuperates the regression reported in https://bugs.openjdk.java.net/browse/JDK-8265523 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Fix as_basic_args_string for adapters with many args, restore NULL-returning behavior ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3706/files - new: https://git.openjdk.java.net/jdk/pull/3706/files/0ace677e..31c8abbf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3706&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3706&range=00-01 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3706.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3706/head:pull/3706 PR: https://git.openjdk.java.net/jdk/pull/3706 From redestad at openjdk.java.net Thu Apr 29 14:47:16 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 29 Apr 2021 14:47:16 GMT Subject: RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters [v2] In-Reply-To: <5QOjFYyn9l3Hav1Ck1kccCQhp25mlHNakefQ4offRDI=.c0b9c446-318f-440a-bf6c-f5c453e06233@github.com> References: <5QOjFYyn9l3Hav1Ck1kccCQhp25mlHNakefQ4offRDI=.c0b9c446-318f-440a-bf6c-f5c453e06233@github.com> Message-ID: On Thu, 29 Apr 2021 04:18:05 GMT, Ioi Lam wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix as_basic_args_string for adapters with many args, restore NULL-returning behavior > > src/hotspot/share/runtime/sharedRuntime.cpp line 2396: > >> 2394: int value = 0; >> 2395: for (int byte = 0; sig_index < total_args_passed && byte < _basic_types_per_int; byte++) { >> 2396: int bt = adapter_encoding(sig_bt[sig_index++]); > > Why is the above changed? Is it for performance? It seems unrelated to this PR. Performance (fingerprints are calculated on every lookup) but also for simplifying the fingerprint iterator in as_basic_args_string: Once we hit total_args_passed, the previous algorithm would keep shifting and adding zero bits until the int is "filled". Now I stop when the last argument has been processed, which meant that iterating becomes simpler. Since the hash function will xor the last value (which is the only one that can have zeros) as a last step, it should also improve how well trailing arguments shuffles low bits. I'm adding some comments, and also fixed a bug in as_basic_args_string when > 8 arguments and changed as_string to not include leading zeroes of the last in (0xbbbbbabb0000000b -> 0xbbbbbabbb) > src/hotspot/share/runtime/sharedRuntime.cpp line 2883: > >> 2881: NOT_PRODUCT(int insts_size = buffer.insts_size()); >> 2882: if (new_adapter == NULL) { >> 2883: fatal("No memory to create adapter"); > > This used to be `return NULL;`, and the JVM is supposed to continue execution (but the linking of the current class will get a VirtualMachineError. I think we should keep the old behavior. Yes, an unintentional result of me breaking the code flow apart and then merging it back together. ------------- PR: https://git.openjdk.java.net/jdk/pull/3706 From dcubed at openjdk.java.net Thu Apr 29 16:15:13 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 29 Apr 2021 16:15:13 GMT Subject: RFR: 8266299: ProblemList runtime/stringtable/StringTableCleaningTest.java on linux-aarch64 with ZGC Message-ID: A trivial fix to ProblemList runtime/stringtable/StringTableCleaningTest.java on linux-aarch64 with ZGC. ------------- Commit messages: - 8266299: ProblemListruntime/stringtable/StringTableCleaningTest.java on linux-aarch64 with ZGC Changes: https://git.openjdk.java.net/jdk/pull/3797/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3797&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266299 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3797/head:pull/3797 PR: https://git.openjdk.java.net/jdk/pull/3797 From bpb at openjdk.java.net Thu Apr 29 16:15:13 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 29 Apr 2021 16:15:13 GMT Subject: RFR: 8266299: ProblemList runtime/stringtable/StringTableCleaningTest.java on linux-aarch64 with ZGC In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 16:04:17 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList runtime/stringtable/StringTableCleaningTest.java on linux-aarch64 with ZGC. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3797 From dcubed at openjdk.java.net Thu Apr 29 16:23:51 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 29 Apr 2021 16:23:51 GMT Subject: RFR: 8266299: ProblemList runtime/stringtable/StringTableCleaningTest.java on linux-aarch64 with ZGC In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 16:09:54 GMT, Brian Burkhalter wrote: >> A trivial fix to ProblemList runtime/stringtable/StringTableCleaningTest.java on linux-aarch64 with ZGC. > > Marked as reviewed by bpb (Reviewer). @bplb - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3797 From minqi at openjdk.java.net Thu Apr 29 17:08:10 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 29 Apr 2021 17:08:10 GMT Subject: RFR: 8263998: Remove mentions of mc region in comments Message-ID: Hi, Please review the simple changes for removing the mc/MC mentioned in comments. "mc" region was removed in fix of https://bugs.openjdk.java.net/browse/JDK-8263002 Tests: local build. Thanks Yumin ------------- Commit messages: - 8263998: Remove mentions of mc region in comments Changes: https://git.openjdk.java.net/jdk/pull/3799/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3799&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263998 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3799.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3799/head:pull/3799 PR: https://git.openjdk.java.net/jdk/pull/3799 From ccheung at openjdk.java.net Thu Apr 29 17:19:54 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 29 Apr 2021 17:19:54 GMT Subject: RFR: 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used In-Reply-To: References: Message-ID: <3Ia_HgdvINqKT1lPqbb0WL7o9a39xpglwRQzdv1AofQ=.f4e40b6e-e97d-43f9-aa1d-d31d94e52d09@github.com> On Thu, 29 Apr 2021 00:32:51 GMT, Ioi Lam wrote: > When CDS tries to load sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo from the classlist, the VM has already finished the "early" bootup phase. To load this class, the module system tries to create an instance of jdk.internal.module.SystemModuleFinders$SystemModuleReader and store that into the ArchivedBootLayer. However, the SystemModuleReader class is also not yet loaded, so the VM loads it on demand. As a result, SystemModuleReader is treated as a "non-early class". > > The problem is now ArchivedBootLayer refers to a non-early class. At runtime, if JVMTI ClassLoadHook is enabled, HeapShared will refuse to load ArchivedBootLayer from the archived heap. The reason is explained by this in heapShared.cpp: > > > // Note: if a ArchivedKlassSubGraphInfoRecord contains non-early classes, and JVMTI > // ClassFileLoadHook is enabled, it's possible for this class to be dynamically replaced. In > // this case, we will not load the ArchivedKlassSubGraphInfoRecord and will clear its roots. > > > However, this doesn't make sense for ArchivedBootLayer -- it's loaded in the early phase at runtime, so any classes referenced by ArchivedBootLayer will also be loaded in the early phase. This means JVMTI ClassLoadHook cannot replace SystemModuleReader. > > Hence, the fix is simple -- for any classes referenced by the 3 "full-module-graph" subgraphs, we always treat them as "early" classes, regardless of when they are loaded during dump time. > > > // Entry fields for subgraphs archived in the open archive heap region (full module graph). > static ArchivableStaticFieldInfo fmg_open_archive_subgraph_entry_fields[] = { > {"jdk/internal/loader/ArchivedClassLoaders", "archivedClassLoaders"}, > {"jdk/internal/module/ArchivedBootLayer", "archivedBootLayer"}, > {"java/lang/Module$ArchivedData", "archivedData"}, > }; > > > The validate the fix, I modified the test case to always load CLDRLocaleDataMetaInfo during dump time. The test failed without the fix and passed with the fix. Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3780 From dcubed at openjdk.java.net Thu Apr 29 17:28:52 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 29 Apr 2021 17:28:52 GMT Subject: Integrated: 8266299: ProblemList runtime/stringtable/StringTableCleaningTest.java on linux-aarch64 with ZGC In-Reply-To: References: Message-ID: <_9ag0yqm71qrdldOactP10c7YDea5kMjdOx4Hl_1Qaw=.4b245b32-bee6-4b19-b0b5-18f2c91dbce0@github.com> On Thu, 29 Apr 2021 16:04:17 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList runtime/stringtable/StringTableCleaningTest.java on linux-aarch64 with ZGC. This pull request has now been integrated. Changeset: 51b2fb5c Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/51b2fb5c848171046d5c2fb822f09d6535a23c4c Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8266299: ProblemList runtime/stringtable/StringTableCleaningTest.java on linux-aarch64 with ZGC Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/3797 From ccheung at openjdk.java.net Thu Apr 29 17:29:50 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 29 Apr 2021 17:29:50 GMT Subject: RFR: 8263998: Remove mentions of mc region in comments In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 16:49:47 GMT, Yumin Qi wrote: > Hi, Please review the simple changes for removing the mc/MC mentioned in comments. "mc" region was removed in fix of > https://bugs.openjdk.java.net/browse/JDK-8263002 > > Tests: local build. > > Thanks > Yumin Looks good and trivial. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3799 From minqi at openjdk.java.net Thu Apr 29 17:33:51 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 29 Apr 2021 17:33:51 GMT Subject: RFR: 8263998: Remove mentions of mc region in comments In-Reply-To: References: Message-ID: <4Lfg8FYstW9V5LCiBK9wuVk4pkxAozZ86xaMkNIdo48=.47d7c5dc-5dd6-45af-8def-56637f10bb19@github.com> On Thu, 29 Apr 2021 17:27:08 GMT, Calvin Cheung wrote: >> Hi, Please review the simple changes for removing the mc/MC mentioned in comments. "mc" region was removed in fix of >> https://bugs.openjdk.java.net/browse/JDK-8263002 >> >> Tests: local build. >> >> Thanks >> Yumin > > Looks good and trivial. @calvinccheung Thanks for quick review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3799 From minqi at openjdk.java.net Thu Apr 29 17:33:52 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 29 Apr 2021 17:33:52 GMT Subject: Integrated: 8263998: Remove mentions of mc region in comments In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 16:49:47 GMT, Yumin Qi wrote: > Hi, Please review the simple changes for removing the mc/MC mentioned in comments. "mc" region was removed in fix of > https://bugs.openjdk.java.net/browse/JDK-8263002 > > Tests: local build. > > Thanks > Yumin This pull request has now been integrated. Changeset: 1afbab63 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/1afbab6394621ebee0d75771a75d19c8c43563d7 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod 8263998: Remove mentions of mc region in comments Reviewed-by: ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/3799 From pchilanomate at openjdk.java.net Thu Apr 29 18:15:58 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 29 Apr 2021 18:15:58 GMT Subject: RFR: 8265933: Move Java monitor related fields from class Thread to JavaThread In-Reply-To: <-m0TGrIg_eNe8NGjlnv_wOME3uQGmFyr-EQGWbJnWdo=.d5c39a17-de42-494d-b861-c32785940e5c@github.com> References: <-m0TGrIg_eNe8NGjlnv_wOME3uQGmFyr-EQGWbJnWdo=.d5c39a17-de42-494d-b861-c32785940e5c@github.com> Message-ID: <2hXQL8jbknlqFDF_-rjGxJnbBHbVr-2NTJMA2OtRupo=.2d2a16bb-20c5-4a54-b1d0-b3fb7dd94c78@github.com> On Wed, 28 Apr 2021 14:05:38 GMT, Robbin Ehn wrote: >> Hi, >> >> Please review the following change. Fields in class Thread related to Java object monitors like _current_pending_monitor, _current_pending_monitor_is_from_java, _current_waiting_monitor and _Stalled should be moved to the JavaThread class. Members _OnTrap and _TypeTag were grouped together with _Stalled but are not used so I removed them. It seems they were part of the ObjectMonitor implementation at some point but I couldn't find how they were used. >> Tested in mach5 tier1-2. >> >> Thanks, >> Patricio > > Marked as reviewed by rehn (Reviewer). Thanks @robehn, @dcubed-ojdk, @dholmes-ora and @coleenp for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3722 From pchilanomate at openjdk.java.net Thu Apr 29 18:15:59 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 29 Apr 2021 18:15:59 GMT Subject: Integrated: 8265933: Move Java monitor related fields from class Thread to JavaThread In-Reply-To: References: Message-ID: <_wzwJ_BCfIq0JpBWpCwxyeV89EmK0gpOu35X9VhPjSY=.0b05bb17-ffc8-4f89-a44f-511affc3757c@github.com> On Tue, 27 Apr 2021 18:08:19 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following change. Fields in class Thread related to Java object monitors like _current_pending_monitor, _current_pending_monitor_is_from_java, _current_waiting_monitor and _Stalled should be moved to the JavaThread class. Members _OnTrap and _TypeTag were grouped together with _Stalled but are not used so I removed them. It seems they were part of the ObjectMonitor implementation at some point but I couldn't find how they were used. > Tested in mach5 tier1-2. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 42af7da9 Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/42af7da94d9ed588a1c526202f6b77773e4e3f95 Stats: 89 lines in 4 files changed: 36 ins; 43 del; 10 mod 8265933: Move Java monitor related fields from class Thread to JavaThread Reviewed-by: rehn, dcubed, coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3722 From iklam at openjdk.java.net Thu Apr 29 19:34:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 29 Apr 2021 19:34:52 GMT Subject: RFR: 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used In-Reply-To: References: Message-ID: <_BM5aWGII47yawJkWlL9yGQXe_Wffi_QLxKYmtHniLE=.261ed048-9823-437f-8475-e7185ab6a981@github.com> On Thu, 29 Apr 2021 05:58:02 GMT, Alan Bateman wrote: > > Does this mean that when using CDS some classes are not subject to the application of the JVM TI ClassFileLoadHook? And if so, is that constraint documented somewhere? > > At one point, enabling the can_generate_all_class_hook_events capability in the onload phase would disable CDS but maybe that has changed? In any case, the only place in the specs where it touches on this is in the CFLH event itself where it has a sentence about not generating the event for some classes. CDS started supporting ClassFileLoadHook since [JDK-8078644](https://bugs.openjdk.java.net/browse/JDK-8078644) (JDK9). At that time, CLFH was enabled for all shared classes. However, since [JDK-8212200](https://bugs.openjdk.java.net/browse/JDK-8212200) (JDK12), we disable CDS when `JvmtiExport::has_early_class_hook_env() == true`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3780 From iklam at openjdk.java.net Thu Apr 29 23:25:55 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 29 Apr 2021 23:25:55 GMT Subject: RFR: 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used In-Reply-To: <3Ia_HgdvINqKT1lPqbb0WL7o9a39xpglwRQzdv1AofQ=.f4e40b6e-e97d-43f9-aa1d-d31d94e52d09@github.com> References: <3Ia_HgdvINqKT1lPqbb0WL7o9a39xpglwRQzdv1AofQ=.f4e40b6e-e97d-43f9-aa1d-d31d94e52d09@github.com> Message-ID: On Thu, 29 Apr 2021 17:17:20 GMT, Calvin Cheung wrote: >> When CDS tries to load sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo from the classlist, the VM has already finished the "early" bootup phase. To load this class, the module system tries to create an instance of jdk.internal.module.SystemModuleFinders$SystemModuleReader and store that into the ArchivedBootLayer. However, the SystemModuleReader class is also not yet loaded, so the VM loads it on demand. As a result, SystemModuleReader is treated as a "non-early class". >> >> The problem is now ArchivedBootLayer refers to a non-early class. At runtime, if JVMTI ClassLoadHook is enabled, HeapShared will refuse to load ArchivedBootLayer from the archived heap. The reason is explained by this in heapShared.cpp: >> >> >> // Note: if a ArchivedKlassSubGraphInfoRecord contains non-early classes, and JVMTI >> // ClassFileLoadHook is enabled, it's possible for this class to be dynamically replaced. In >> // this case, we will not load the ArchivedKlassSubGraphInfoRecord and will clear its roots. >> >> >> However, this doesn't make sense for ArchivedBootLayer -- it's loaded in the early phase at runtime, so any classes referenced by ArchivedBootLayer will also be loaded in the early phase. This means JVMTI ClassLoadHook cannot replace SystemModuleReader. >> >> Hence, the fix is simple -- for any classes referenced by the 3 "full-module-graph" subgraphs, we always treat them as "early" classes, regardless of when they are loaded during dump time. >> >> >> // Entry fields for subgraphs archived in the open archive heap region (full module graph). >> static ArchivableStaticFieldInfo fmg_open_archive_subgraph_entry_fields[] = { >> {"jdk/internal/loader/ArchivedClassLoaders", "archivedClassLoaders"}, >> {"jdk/internal/module/ArchivedBootLayer", "archivedBootLayer"}, >> {"java/lang/Module$ArchivedData", "archivedData"}, >> }; >> >> >> The validate the fix, I modified the test case to always load CLDRLocaleDataMetaInfo during dump time. The test failed without the fix and passed with the fix. > > Looks good. Thanks @calvinccheung @dholmes-ora @yminqi for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3780 From iklam at openjdk.java.net Thu Apr 29 23:25:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 29 Apr 2021 23:25:56 GMT Subject: Integrated: 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 00:32:51 GMT, Ioi Lam wrote: > When CDS tries to load sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo from the classlist, the VM has already finished the "early" bootup phase. To load this class, the module system tries to create an instance of jdk.internal.module.SystemModuleFinders$SystemModuleReader and store that into the ArchivedBootLayer. However, the SystemModuleReader class is also not yet loaded, so the VM loads it on demand. As a result, SystemModuleReader is treated as a "non-early class". > > The problem is now ArchivedBootLayer refers to a non-early class. At runtime, if JVMTI ClassLoadHook is enabled, HeapShared will refuse to load ArchivedBootLayer from the archived heap. The reason is explained by this in heapShared.cpp: > > > // Note: if a ArchivedKlassSubGraphInfoRecord contains non-early classes, and JVMTI > // ClassFileLoadHook is enabled, it's possible for this class to be dynamically replaced. In > // this case, we will not load the ArchivedKlassSubGraphInfoRecord and will clear its roots. > > > However, this doesn't make sense for ArchivedBootLayer -- it's loaded in the early phase at runtime, so any classes referenced by ArchivedBootLayer will also be loaded in the early phase. This means JVMTI ClassLoadHook cannot replace SystemModuleReader. > > Hence, the fix is simple -- for any classes referenced by the 3 "full-module-graph" subgraphs, we always treat them as "early" classes, regardless of when they are loaded during dump time. > > > // Entry fields for subgraphs archived in the open archive heap region (full module graph). > static ArchivableStaticFieldInfo fmg_open_archive_subgraph_entry_fields[] = { > {"jdk/internal/loader/ArchivedClassLoaders", "archivedClassLoaders"}, > {"jdk/internal/module/ArchivedBootLayer", "archivedBootLayer"}, > {"java/lang/Module$ArchivedData", "archivedData"}, > }; > > > The validate the fix, I modified the test case to always load CLDRLocaleDataMetaInfo during dump time. The test failed without the fix and passed with the fix. This pull request has now been integrated. Changeset: 2c381e0f Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/2c381e0f8d5777d289a6eb410d66d8221c7d9d1b Stats: 19 lines in 2 files changed: 12 ins; 3 del; 4 mod 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used Reviewed-by: dholmes, minqi, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/3780 From whuang at openjdk.java.net Fri Apr 30 03:34:22 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 30 Apr 2021 03:34:22 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v6] In-Reply-To: References: Message-ID: > As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix crash problem ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3392/files - new: https://git.openjdk.java.net/jdk/pull/3392/files/7cd04c94..adaffaac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=04-05 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3392.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3392/head:pull/3392 PR: https://git.openjdk.java.net/jdk/pull/3392 From whuang at openjdk.java.net Fri Apr 30 03:34:22 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 30 Apr 2021 03:34:22 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v5] In-Reply-To: <0MLIgTj_K99D27FlPQyKJ1VglX4wNWFRDjd0CS-XmM0=.168b02ac-c2e1-451d-801f-e85d72fff543@github.com> References: <0MLIgTj_K99D27FlPQyKJ1VglX4wNWFRDjd0CS-XmM0=.168b02ac-c2e1-451d-801f-e85d72fff543@github.com> Message-ID: On Wed, 28 Apr 2021 20:22:51 GMT, David Holmes wrote: > I was unable to reproduce the test failure locally. Thank you for your feedback. I have reproduced this problem (~ 10% ) and fixed it. Could you give me a favor to review new commit ? Thank you very much. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From dholmes at openjdk.java.net Fri Apr 30 05:32:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 05:32:53 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v6] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 03:34:22 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix crash problem I don't see exactly why the lack of join() would lead to the test failure, but doing the join() is cleaner and consistent with what other tests do. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3392 From whuang at openjdk.java.net Fri Apr 30 06:15:52 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 30 Apr 2021 06:15:52 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v6] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 05:29:53 GMT, David Holmes wrote: > I don't see exactly why the lack of join() would lead to the test failure, but doing the join() is cleaner and consistent with what other tests do. > > Thanks, > David The reason is that the main thread needs to exit and wait for the other two threads to exit. However, the `jtreg` just waits for a fix time. If two threads are not scheduled in this time, an error will be triggered. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From dholmes at openjdk.java.net Fri Apr 30 07:37:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 07:37:53 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v6] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 03:34:22 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix crash problem We actually need a second review here (hotspot group rules). Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From whuang at openjdk.java.net Fri Apr 30 07:44:53 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 30 Apr 2021 07:44:53 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v6] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 07:35:00 GMT, David Holmes wrote: > hotspot group rules Sure. It's my fault. Is there any way to revoke `/integrate` here? ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From dholmes at openjdk.java.net Fri Apr 30 09:12:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 09:12:52 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v6] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 03:34:22 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix crash problem No need to revoke it, the sponsor just needs to hold off until there is a second review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From lzang at openjdk.java.net Fri Apr 30 09:18:57 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 30 Apr 2021 09:18:57 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v20] In-Reply-To: <-qf3V7rOYbOMN9Wf0Q4Nnuz8seoJwA6VeUBQgqLVnak=.ace9f2ac-4669-4c2e-990a-1547533094cc@github.com> References: <9Q69ICl9o5uaRsoDDEa43b9Vl21lzaZIHe2f8mvQy7c=.b1b36b58-787a-4950-9afe-31ca4c79165b@github.com> <-qf3V7rOYbOMN9Wf0Q4Nnuz8seoJwA6VeUBQgqLVnak=.ace9f2ac-4669-4c2e-990a-1547533094cc@github.com> Message-ID: On Wed, 21 Apr 2021 18:40:16 GMT, Chris Plummer wrote: >>> My concerns with your proposed testing is that it always targets the same application with the same heap, and does not read/process the hprof file to make sure it is not corrupt. >> >> Hmm, I agree, I will do more test and update here. Thanks! > >> > My concerns with your proposed testing is that it always targets the same application with the same heap, and does not read/process the hprof file to make sure it is not corrupt. >> >> Hmm, I agree, I will do more test and update here. Thanks! > > As for jtreg testing, we have a few heap dumping related tests. I'm not sure how good they are. It would be good to understand what testing we currently do. > > In addition to jtreg testing, you might want to try just launching some large java apps (netbeans and intellij come to mind), dump their heaps, and then process them with some existing tool. I'm not suggesting this be part of regular testing, but just a sanity check you do on your own before pushing the changes. Hi Chris, @plummercj Here are the tests I have conducted: - tier1, tier2,tier3 all passed - netbeans with heap usage of 500mb, 1000mb, plus "randomly do some operation and dump the heap". tested 30 times and all passed. - a workload that generate different object to fill heap, I have tested with heap usage from 1GB to 8GB. All passed. All the scenario are tested with/without the gz option. Do you think these tests are ok? BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From dholmes at openjdk.java.net Fri Apr 30 09:34:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 09:34:13 GMT Subject: RFR: 8255566: Initialize JDK_Version direct from the build system Message-ID: The existing logic does: build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class we can simply do: build system -> JDK_Version class reduces footprint, loc and startup time. Testing tiers 1-3 and manual visual inspection of version strings Thanks, David ------------- Commit messages: - 8255566: Initialize JDK_Version direct from the build system Changes: https://git.openjdk.java.net/jdk/pull/3812/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3812&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255566 Stats: 86 lines in 5 files changed: 7 ins; 74 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3812/head:pull/3812 PR: https://git.openjdk.java.net/jdk/pull/3812 From avoitylov at openjdk.java.net Fri Apr 30 10:58:52 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 30 Apr 2021 10:58:52 GMT Subject: RFR: JDK-8263396: Atomic::CmpxchgByteUsingInt::set_byte_in_int needs an explicit cast In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 18:15:40 GMT, Aleksei Voitylov wrote: > Hi, > > please review this PR to fix a problem found by SonarCloud. I think it's best to fix it to avoid confusion. > > As required by the standard, operands of arithmetical operators are implicitly promoted to at least int. Code being fixed assumes int to be at least 32 bits and all implicit promotions are performed to at least 32 bits. It's not a problem with any of the platforms supported by OpenJDK but it won't work correctly on platforms and compilers with 16 bit ints: shift operators will use 16 bit integer and anything shifted to bits 16:31 will be lost. > > Testing: original case with gcc bug on Arm 32 is not reproduced, pre-submit tests were run. Thank you David for the review. I agree with your assessment, just wanted to make sure not to spend time on this the next scanner shows this up. I assume the fix to be trivial. ------------- PR: https://git.openjdk.java.net/jdk/pull/3723 From pliden at openjdk.java.net Fri Apr 30 12:19:20 2021 From: pliden at openjdk.java.net (Per Liden) Date: Fri, 30 Apr 2021 12:19:20 GMT Subject: RFR: 8266056: runtime/stringtable/StringTableCleaningTest.java failed with "RuntimeException: Missing Callback in [10, 11]" Message-ID: This patch addresses two issues with the StringTableCleaningTest test. 1) The test doesn't fully take into account that a concurrent GC might not complete (it can abort if the VM wants to terminate). findCallback() should return -1 if no callbacks are found, instead of failing the test. 2) The regexp patterns used for ZGC needs to be more exact. The end pattern now also matches aborted GCs, which it shouldn't. This leads to "Garbage Collection (*) Aborted" being incorrectly matched as a GC end. This patch also makes sure the output from the test VM ends up in the test log, otherwise it's impossible to tell what went wrong if this test fails in the future. This patch also removes the test from the ProblemList. Testing: * Passed Tier1-3. * Manual testing of StringTableCleaningTest with various GCs. ------------- Commit messages: - 8266056: runtime/stringtable/StringTableCleaningTest.java failed with "RuntimeException: Missing Callback in [10, 11]" Changes: https://git.openjdk.java.net/jdk/pull/3815/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3815&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266056 Stats: 8 lines in 2 files changed: 3 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3815.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3815/head:pull/3815 PR: https://git.openjdk.java.net/jdk/pull/3815 From coleenp at openjdk.java.net Fri Apr 30 12:23:53 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 30 Apr 2021 12:23:53 GMT Subject: RFR: 8266056: runtime/stringtable/StringTableCleaningTest.java failed with "RuntimeException: Missing Callback in [10, 11]" In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 12:08:00 GMT, Per Liden wrote: > This patch addresses two issues with the StringTableCleaningTest test. > > 1) The test doesn't fully take into account that a concurrent GC might not complete (it can abort if the VM wants to terminate). findCallback() should return -1 if no callbacks are found, instead of failing the test. > > 2) The regexp patterns used for ZGC needs to be more exact. The end pattern now also matches aborted GCs, which it shouldn't. This leads to "Garbage Collection (*) Aborted" being incorrectly matched as a GC end. > > This patch also makes sure the output from the test VM ends up in the test log, otherwise it's impossible to tell what went wrong if this test fails in the future. > > This patch also removes the test from the ProblemList. > > Testing: > * Passed Tier1-3. > * Manual testing of StringTableCleaningTest with various GCs. Looks good and trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3815 From avoitylov at openjdk.java.net Fri Apr 30 12:37:51 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 30 Apr 2021 12:37:51 GMT Subject: Integrated: JDK-8263396: Atomic::CmpxchgByteUsingInt::set_byte_in_int needs an explicit cast In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 18:15:40 GMT, Aleksei Voitylov wrote: > Hi, > > please review this PR to fix a problem found by SonarCloud. I think it's best to fix it to avoid confusion. > > As required by the standard, operands of arithmetical operators are implicitly promoted to at least int. Code being fixed assumes int to be at least 32 bits and all implicit promotions are performed to at least 32 bits. It's not a problem with any of the platforms supported by OpenJDK but it won't work correctly on platforms and compilers with 16 bit ints: shift operators will use 16 bit integer and anything shifted to bits 16:31 will be lost. > > Testing: original case with gcc bug on Arm 32 is not reproduced, pre-submit tests were run. This pull request has now been integrated. Changeset: eb8db12c Author: Aleksei Voitylov Committer: David Holmes URL: https://git.openjdk.java.net/jdk/commit/eb8db12ce67b10957fa94fbf61d9a30db34ec01a Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8263396: Atomic::CmpxchgByteUsingInt::set_byte_in_int needs an explicit cast Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3723 From dholmes at openjdk.java.net Fri Apr 30 12:42:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 12:42:11 GMT Subject: RFR: 8266056: runtime/stringtable/StringTableCleaningTest.java failed with "RuntimeException: Missing Callback in [10, 11]" In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 12:08:00 GMT, Per Liden wrote: > This patch addresses two issues with the StringTableCleaningTest test. > > 1) The test doesn't fully take into account that a concurrent GC might not complete (it can abort if the VM wants to terminate). findCallback() should return -1 if no callbacks are found, instead of failing the test. > > 2) The regexp patterns used for ZGC needs to be more exact. The end pattern now also matches aborted GCs, which it shouldn't. This leads to "Garbage Collection (*) Aborted" being incorrectly matched as a GC end. > > This patch also makes sure the output from the test VM ends up in the test log, otherwise it's impossible to tell what went wrong if this test fails in the future. > > This patch also removes the test from the ProblemList. > > Testing: > * Passed Tier1-3. > * Manual testing of StringTableCleaningTest with various GCs. Functional fix seems fine but a suggested change to the reporting. Thanks, David test/hotspot/jtreg/runtime/stringtable/StringTableCleaningTest.java line 63: > 61: OutputAnalyzer output = ProcessTools.executeTestJvm(subargs); > 62: output.outputTo(System.out); > 63: output.errorTo(System.out); The normal way to do this is to call output.reportDiagnosticSummary(). But you only do that after the actual checks, when you know you have success, as in the error cases it will be called anyway and you don't want the output twice. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3815 From erikj at openjdk.java.net Fri Apr 30 12:47:51 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 30 Apr 2021 12:47:51 GMT Subject: RFR: 8255566: Initialize JDK_Version direct from the build system In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 09:19:57 GMT, David Holmes wrote: > The existing logic does: > > build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class > > we can simply do: > > build system -> JDK_Version class > > reduces footprint, loc and startup time. > > Testing tiers 1-3 and manual visual inspection of version strings > > Thanks, > David Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3812 From dholmes at openjdk.java.net Fri Apr 30 12:47:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 12:47:52 GMT Subject: RFR: 8255566: Initialize JDK_Version direct from the build system In-Reply-To: References: Message-ID: <1kv8EogCRlZa5u4wzSxW-5ttSbon-kIFr72IMvJcGhg=.3ddfc9eb-07cb-45a0-b4db-48dbe7fb7a95@github.com> On Fri, 30 Apr 2021 09:19:57 GMT, David Holmes wrote: > The existing logic does: > > build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class > > we can simply do: > > build system -> JDK_Version class > > reduces footprint, loc and startup time. > > Testing tiers 1-3 and manual visual inspection of version strings > > Thanks, > David I think I may have overlooked something here as I have a failing test. It looks like there may be a way to override the build-time values. ------------- PR: https://git.openjdk.java.net/jdk/pull/3812 From dholmes at openjdk.java.net Fri Apr 30 12:47:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 12:47:52 GMT Subject: Withdrawn: 8255566: Initialize JDK_Version direct from the build system In-Reply-To: References: Message-ID: <01Y6KrP6qw8MGaYo67K-McJaCLogfdeEDsspNuv_y9g=.3274a87d-bbc3-4978-8fc7-3b7edaf00af4@github.com> On Fri, 30 Apr 2021 09:19:57 GMT, David Holmes wrote: > The existing logic does: > > build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class > > we can simply do: > > build system -> JDK_Version class > > reduces footprint, loc and startup time. > > Testing tiers 1-3 and manual visual inspection of version strings > > Thanks, > David This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3812 From dholmes at openjdk.java.net Fri Apr 30 12:52:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 30 Apr 2021 12:52:56 GMT Subject: RFR: 8255566: Initialize JDK_Version direct from the build system In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 09:19:57 GMT, David Holmes wrote: > The existing logic does: > > build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class > > we can simply do: > > build system -> JDK_Version class > > reduces footprint, loc and startup time. > > Testing tiers 1-3 and manual visual inspection of version strings > > Thanks, > David I missed the fact that the VENDOR_VERSION and VENDOR_URL_VM_BUG values can be set programmatically by the jlink plugin, and so are different from the configure-time values. The VM has to continue to read those from VersionProps. ------------- PR: https://git.openjdk.java.net/jdk/pull/3812 From pliden at openjdk.java.net Fri Apr 30 13:08:15 2021 From: pliden at openjdk.java.net (Per Liden) Date: Fri, 30 Apr 2021 13:08:15 GMT Subject: RFR: 8266056: runtime/stringtable/StringTableCleaningTest.java failed with "RuntimeException: Missing Callback in [10, 11]" [v2] In-Reply-To: References: Message-ID: <48rwfXGoo5MF4daRoiJ_6-mPKs6S49GOyp6wk45i60o=.1b9ebaa6-e85f-4abe-9222-8aa01903d9f5@github.com> > This patch addresses two issues with the StringTableCleaningTest test. > > 1) The test doesn't fully take into account that a concurrent GC might not complete (it can abort if the VM wants to terminate). findCallback() should return -1 if no callbacks are found, instead of failing the test. > > 2) The regexp patterns used for ZGC needs to be more exact. The end pattern now also matches aborted GCs, which it shouldn't. This leads to "Garbage Collection (*) Aborted" being incorrectly matched as a GC end. > > This patch also makes sure the output from the test VM ends up in the test log, otherwise it's impossible to tell what went wrong if this test fails in the future. > > This patch also removes the test from the ProblemList. > > Testing: > * Passed Tier1-3. > * Manual testing of StringTableCleaningTest with various GCs. Per Liden has updated the pull request incrementally with one additional commit since the last revision: Review comments from David ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3815/files - new: https://git.openjdk.java.net/jdk/pull/3815/files/f98123ce..d991bbc3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3815&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3815&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3815.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3815/head:pull/3815 PR: https://git.openjdk.java.net/jdk/pull/3815 From pliden at openjdk.java.net Fri Apr 30 13:08:16 2021 From: pliden at openjdk.java.net (Per Liden) Date: Fri, 30 Apr 2021 13:08:16 GMT Subject: RFR: 8266056: runtime/stringtable/StringTableCleaningTest.java failed with "RuntimeException: Missing Callback in [10, 11]" [v2] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 12:36:13 GMT, David Holmes wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments from David > > test/hotspot/jtreg/runtime/stringtable/StringTableCleaningTest.java line 63: > >> 61: OutputAnalyzer output = ProcessTools.executeTestJvm(subargs); >> 62: output.outputTo(System.out); >> 63: output.errorTo(System.out); > > The normal way to do this is to call output.reportDiagnosticSummary(). But you only do that after the actual checks, when you know you have success, as in the error cases it will be called anyway and you don't want the output twice. Hmm, I see now that adding lines those is unnecessary, so I'll just remove them. Both shouldHaveExitValue() and checkOutput() seem to do the right thing. Not sure why I thought they didn't. ------------- PR: https://git.openjdk.java.net/jdk/pull/3815 From hseigel at openjdk.java.net Fri Apr 30 13:09:55 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 30 Apr 2021 13:09:55 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v6] In-Reply-To: References: Message-ID: <8fvZd9xUC5bt0UpkviNFeth3iJS5NrHi9Aiv1a97rL0=.f0252147-eeef-4a4d-bf00-f12478a7f7ab@github.com> On Fri, 30 Apr 2021 03:34:22 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix crash problem test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 34: > 32: * @run main TestNestHostErrorWithMultiThread > 33: */ > 34: Please add a comment here that HostNoNestMember.jcod must be compiled after HostNoNestMember.java because the class file from the jcod file must replace the HostNoNestMember class file generated from HostNoNestMember.java. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From coleenp at openjdk.java.net Fri Apr 30 13:15:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 30 Apr 2021 13:15:52 GMT Subject: RFR: 8255566: Initialize JDK_Version direct from the build system In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 09:19:57 GMT, David Holmes wrote: > The existing logic does: > > build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static buffers -> JDK_Version class > > we can simply do: > > build system -> JDK_Version class > > reduces footprint, loc and startup time. > > Testing tiers 1-3 and manual visual inspection of version strings > > Thanks, > David A bit late but this is a nice cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/3812 From hseigel at openjdk.java.net Fri Apr 30 13:30:56 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 30 Apr 2021 13:30:56 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v6] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 03:34:22 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix crash problem test/hotspot/jtreg/runtime/Nestmates/membership/HostNoNestMember.java line 29: > 27: * HostNoNestMember$Member has a class HostNoNestMember as its > 28: * NestHost, which will trigger an error when resolving . > 29: */ Can you modify the above comment to something such as: * This class was used to produce a jcod file in which the * NestMembers attribute was modified to make it empty. Class * HostNoNestMember$Member has class HostNoNestMember as its * NestHost, which will trigger an error when resolving. * * When compiled, this generates a HostNoNestMember class and * a HostNoNestMember$Menber class. The former class, HostNoNestMember, * gets overwritten when HostNoNestMember.jcod gets compiled. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From vromero at openjdk.java.net Fri Apr 30 17:40:47 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 30 Apr 2021 17:40:47 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v5] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero 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 ten additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - 8260517: Compiler implementation for Sealed Classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/43e9cb5f..2744f615 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=03-04 Stats: 506473 lines in 3844 files changed: 20558 ins; 483521 del; 2394 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From redestad at openjdk.java.net Fri Apr 30 18:44:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 30 Apr 2021 18:44:08 GMT Subject: RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters [v3] In-Reply-To: References: Message-ID: > This patch refactors AdapterHandlerLibrary initialization so that we can initialize a handful of commonly used adapters early during bootstrap, and avoid taking the AdapterHandlerLibrary_lock when looking up these adapters. > > Since the 5 most common adapters plus the abstract adapter constitutes roughly 60% of the method shapes loaded and linked on a Hello World, this means a relatively significant startup optimization (~2M insns on Hello World); most of the win is in lookup code that will be a significant part of the cost of class loading even when no adapters need to be generated. > > This enhancement partially recuperates the regression reported in https://bugs.openjdk.java.net/browse/JDK-8265523 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Use a SignatureIterator to calculate the sig_bt array to allow taking advantage of the method fingerprint ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3706/files - new: https://git.openjdk.java.net/jdk/pull/3706/files/31c8abbf..2bbb1198 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3706&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3706&range=01-02 Stats: 55 lines in 1 file changed: 42 ins; 10 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3706.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3706/head:pull/3706 PR: https://git.openjdk.java.net/jdk/pull/3706 From redestad at openjdk.java.net Fri Apr 30 19:04:57 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 30 Apr 2021 19:04:57 GMT Subject: RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters [v3] In-Reply-To: <5QOjFYyn9l3Hav1Ck1kccCQhp25mlHNakefQ4offRDI=.c0b9c446-318f-440a-bf6c-f5c453e06233@github.com> References: <5QOjFYyn9l3Hav1Ck1kccCQhp25mlHNakefQ4offRDI=.c0b9c446-318f-440a-bf6c-f5c453e06233@github.com> Message-ID: On Thu, 29 Apr 2021 04:49:30 GMT, Ioi Lam wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Use a SignatureIterator to calculate the sig_bt array to allow taking advantage of the method fingerprint > > Looks good overall, but I think we should avoid changing the `return NULL` to `fatal()`. > > Also note to other reviewers: when looking at the "Files changed", add `&w=1` to the URL so GitHub will ignore whitespace changes. @iklam asked me offline to experiment using a concurrent hash table keyed on fingerprint to create a quick filter. I've done a few prototypes and verified that a concurrent hash table alone[1] does perform roughly as well as this patch on a few sampled applications, and that combining the current patch with a concurrent hash table comes out slightly ahead of both[2]. But this comes at a cost of an additional data structure that might grow to non-trivial size. After analyzing the most significant part of the difference comes not from a reduction in `Mutex` overhead (~400k insts) but from a reduction in `SignatureStream` parsing (~1.2M insns). Using a `SignatureIterator` that takes the method fingerprint into account gets us ahead of the combined `ConcurrentHashTable` experiment, without needing to add another data structure. For a follow-up to this it might make sense to re-implement `AdapterHandlerLibrary::_adapters` as a `ConcurrentHashTable` rather than a `BasicHashtable`. [1] https://github.com/openjdk/jdk/compare/master...cl4es:adapter_cht_only?expand=1 [2] https://github.com/openjdk/jdk/compare/master...cl4es:adapter_cht_combined?expand=1 ------------- PR: https://git.openjdk.java.net/jdk/pull/3706 From cjplummer at openjdk.java.net Fri Apr 30 19:24:03 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 30 Apr 2021 19:24:03 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v21] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 12:45:56 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Merge branch 'master' into par-dump > - refine with several fix > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - remove parallel option and dumpheapext command > - Revert "hide the dumpheapext error message" > > This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. > - resize large object threshold > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - ... and 17 more: https://git.openjdk.java.net/jdk/compare/c3ac6900...6d14790a Hi Lin, Yes, that seems like sufficient testing. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From cjplummer at openjdk.java.net Fri Apr 30 19:30:00 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 30 Apr 2021 19:30:00 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v21] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 12:45:56 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Merge branch 'master' into par-dump > - refine with several fix > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - remove parallel option and dumpheapext command > - Revert "hide the dumpheapext error message" > > This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. > - resize large object threshold > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - ... and 17 more: https://git.openjdk.java.net/jdk/compare/c3ac6900...6d14790a src/hotspot/share/services/heapDumperCompression.hpp line 222: > 220: char const* error() const { return _err; } > 221: > 222: // Sets up an internal buffer, fill with external buffer, and sends to compressor. "fills" ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From cjplummer at openjdk.java.net Fri Apr 30 19:34:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 30 Apr 2021 19:34:07 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v21] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 12:45:56 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Merge branch 'master' into par-dump > - refine with several fix > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - remove parallel option and dumpheapext command > - Revert "hide the dumpheapext error message" > > This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. > - resize large object threshold > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - ... and 17 more: https://git.openjdk.java.net/jdk/compare/c3ac6900...6d14790a src/hotspot/share/services/heapDumperCompression.cpp line 240: > 238: } > 239: > 240: void CompressionBackend::flush_buffer_without_lock(MonitorLocker* ml) { I'm trying to think of a better name since "without_lock" makes it sound like there is no locking, but there is. The difference is the lock is passed in. How about just calling it `flush_buffer(MonitorLocker* ml)` and rely on C++ method overloading to disambiguate it from `flush_buffer()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From dcubed at openjdk.java.net Fri Apr 30 19:40:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 19:40:58 GMT Subject: RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64 Message-ID: A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. ------------- Commit messages: - 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64 Changes: https://git.openjdk.java.net/jdk/pull/3824/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3824&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266389 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3824.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3824/head:pull/3824 PR: https://git.openjdk.java.net/jdk/pull/3824 From mikael at openjdk.java.net Fri Apr 30 19:40:58 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 30 Apr 2021 19:40:58 GMT Subject: RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64 In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:32:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From prr at openjdk.java.net Fri Apr 30 19:52:18 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 30 Apr 2021 19:52:18 GMT Subject: RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:32:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. Please make it generic ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From dcubed at openjdk.java.net Fri Apr 30 19:52:17 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 19:52:17 GMT Subject: RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all [v2] In-Reply-To: References: Message-ID: > A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Use 'generic-all' for java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java entry. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3824/files - new: https://git.openjdk.java.net/jdk/pull/3824/files/40fd5576..4750d33f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3824&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3824&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3824.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3824/head:pull/3824 PR: https://git.openjdk.java.net/jdk/pull/3824 From dcubed at openjdk.java.net Fri Apr 30 19:52:19 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 19:52:19 GMT Subject: RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:32:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. Will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From prr at openjdk.java.net Fri Apr 30 19:52:20 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 30 Apr 2021 19:52:20 GMT Subject: RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all [v2] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:49:17 GMT, Daniel D. Daugherty wrote: >> A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Use 'generic-all' for java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java entry. test/jdk/ProblemList.txt line 529: > 527: java/awt/MenuBar/TestNoScreenMenuBar.java 8265987 macosx-all > 528: > 529: java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java 8266283 linux-all generic like it used to be please ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From mikael at openjdk.java.net Fri Apr 30 19:52:18 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 30 Apr 2021 19:52:18 GMT Subject: RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all [v2] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:49:17 GMT, Daniel D. Daugherty wrote: >> A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Use 'generic-all' for java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java entry. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From dcubed at openjdk.java.net Fri Apr 30 19:57:55 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 19:57:55 GMT Subject: RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all [v2] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:46:46 GMT, Mikael Vidstedt wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Use 'generic-all' for java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java entry. > > Marked as reviewed by mikael (Reviewer). @vidmik and @prrace - Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From prr at openjdk.java.net Fri Apr 30 19:57:55 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 30 Apr 2021 19:57:55 GMT Subject: RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all [v2] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:52:17 GMT, Daniel D. Daugherty wrote: >> A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Use 'generic-all' for java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java entry. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From dcubed at openjdk.java.net Fri Apr 30 19:57:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 19:57:56 GMT Subject: Integrated: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:32:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. This pull request has now been integrated. Changeset: 50fa1623 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/50fa1623adca74f79413fd127d4338901da4678d Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all Reviewed-by: mikael, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From dcubed at openjdk.java.net Fri Apr 30 20:57:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 20:57:53 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> References: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> Message-ID: <4VOXQ7X3vPyTIQJQ38PdExpGKj3f_ABeABa2ZDquBSg=.813d4dba-f14e-421f-811e-f2b65420fdaa@github.com> On Wed, 28 Apr 2021 12:55:18 GMT, David Holmes wrote: >> The synopsis pretty much says it all. There's a more detailed history in the RFE itself. >> >> Currently running the new test thru Mach5 Tier[1-7]. >> I've run the test thru several 12 hour runs on my MBP13 and >> on my Linux-X64 server. > > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 30: > >> 28: * non-null string for a blocked thread and then makes repeated calls >> 29: * to getThreadInfo() and ThreadInfo.getLockOwnerName() until the thread >> 30: * has exited. > > Extra space before has. Fixed. > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 33: > >> 31: * @requires vm.jvmti >> 32: * @library /test/lib >> 33: * @compile getLockOwnerName.java > > You don't need a @compile statement for the current test file Deleted. > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 137: > >> 135: } >> 136: >> 137: System.exit(run(timeMax, System.out) + exit_delta); > > jtreg tests don't use System.exit! Hmmm... that's generally true, but this is a test that must be run as "othervm" so this style of exit with the "+ exit_delta" logic has been used for these kinds of stress tests. I think this style came from the VMTestbase tests and I've used it with other stress tests. > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 189: > >> 187: while (testState != TS_BLOCKER_RUNNING) { >> 188: try { >> 189: barrierLaunch.wait(0); // wait until it is running > > Nit: we use wait() rather than wait(0) I fixed it in 5 places. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Fri Apr 30 20:57:52 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 20:57:52 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:08:52 GMT, Daniel D. Daugherty wrote: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. @dholmes-ora - Thanks for the review. Sorry for the delay in responding. I've been working on other issues. Please see my embedded replies. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Fri Apr 30 21:50:25 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 21:50:25 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v2] In-Reply-To: References: Message-ID: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: dholmes CR changes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3478/files - new: https://git.openjdk.java.net/jdk/pull/3478/files/f6fbf715..682a7c9d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478 PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Fri Apr 30 23:57:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 23:57:37 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v3] In-Reply-To: References: Message-ID: <5C70XkosbvCKiIcgWrlbTY0elIateAXiSG5oSROGmm4=.0ca72fb3-460b-4e35-be8d-49a73472babe@github.com> > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Daniel D. Daugherty 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 JDK-8265153 - dholmes CR changes. - 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3478/files - new: https://git.openjdk.java.net/jdk/pull/3478/files/682a7c9d..3b4004d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=01-02 Stats: 568378 lines in 5345 files changed: 48342 ins; 511803 del; 8233 mod Patch: https://git.openjdk.java.net/jdk/pull/3478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478 PR: https://git.openjdk.java.net/jdk/pull/3478